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为 什么 写 这 本 书 


2009 年 5 月 份 ， 我 在 JavaEye 上 发 了 一 个 帖子 ， 其 中 提 到 目 己 已 经 
工作 9 年 了 ， 总 觉得 这 9 年 不 应 该 吏 这 么 大 废 了 ， 应 该 给 目 己 这 9 年 的 工 


作 写 一 个 总 结 ， 总 结 的 初稿 就 古 这 本 书 。 


在 谈 为 什么 写 这 本 书 之 前 ， 先 拌 拌 自己 前 9 年 的 职业 生涯 吧 。 大 学 
时 我 是 学 习 机 械 的 ， 当 时 计算 机 刚刚 热 起 来 ， 自 己 也 喜欢 玩 一 些 新 奇 
的 东西 ， 记 得 最 清楚 的 是 用 VB 写 了 一 个 自由 落体 的 小 程序 ， 模 拟 小 球 
从 桌面 挥 到 地 板 上 ， 然 后 计算 反弹 趋势 ， 很 有 成 就 感 。 于 是 2000 年 毕 
业 时 ， 我 前 尖 了 脑袋 进入 了 IJ 行业， 成 为 了 一 名 真正 的 工 男 ， 干 着 起 
得 比 鸡 早 、 皮 得 比 狗 晚 的 程序 员工 作 ，IT 男 的 圣 酸 有 谁 知 晓 ! 


坦 日 地 说 ， 我 的 性 格 比 较 帝 癌 ， 属 于 典型 的 程序 员 型 癌 又， 比较 
适合 做 技术 研究。 在 这 9 年 里 ， 项 目 管理 做 过 ， 系 统 分 析 做 过 ， 人 小兵 当 
过 ， 团 队 领导 人 也 当 过 ， 但 至 今 还 是 一 个 做 扩 术 的 。 要 总 结 这 9 年 技术 
生涯 ， 忆 得 写 点 什么 吧 ， 最 好 是 还 能 对 其 他 人 有 点 儿 用 的 。 那 写 什么 
好 呢 ?Spring、Struts 等 工具 框架 类 的 书 太 多 太 多 ， 很 难 再 写 出 伦 样 
来 ， 经 过 一 番 思 考 ， 最 后 选择 了 一 个 每 一 位 技术 人 员 都 需要 掌握 的 、 


但 普及 程度 还 不 是 非常 高 的 、 又 稍微 有 点 难度 的 主题 一 一 设 计 模 式 
(Design Pattern，DP) 。 


中 国人 有 不 破 不 立 的 思维 ， 远 的 如 秦 始 旦 侈 书 坑 儒 、 项 羽 火 烧 阿 
房 品 ， 近 的 如 破 “ 四 旧 ”。 正 古 由 于 有 了 这 样 的 思想 ， 于 十 乎 能 改 的 就 
改 ， 不 能 改 的 束 推 翻 重 写 ， 没 有 一 个 持续 开发 监 图 。 为 什么 要 破 才 能 
立 呢 ? 为 什么 不 能 持续 地 发 展 ? 你 说 这 是 谁 的 错 呢 ? 征 你 染 构 师 的 
错 ， 你 不 能 持续 地 拥抱 变化 ， 这 十 一 个 系统 最 失败 的 地 方 。 那 怎么 才 
能 实现 拥抱 变化 的 理想 昵 ? 设计 模式 ! 


设计 模式 是 什么 ? 它 是 一 套 理论 ， 由 软件 界 的 先辈 们 (The Gang 
of Four: 包括 Erich Gamma、Richard Helm、Ralph Johnson、John 
Vlissides) 总 结 出 的 一 套 可 以 反复 使 用 的 经 验 ， 它 可 以 提高 代码 的 可 
重用 性 ， 增 强 系统 的 可 维护 性 ， 以 及 解决 一 系列 的 复杂 问题 。 做 软件 
的 人 都 知道 需求 是 最 难 把 握 的 ， 我 们 可 以 分 析 现 有 的 需求 ， 预 测 可 能 
发 生 的 变更 ,但 是 我 们 不 能 控制 需求 的 变更 。 问 题 来 了 ， 既 然 需 求 的 
变更 是 不 可 控 的 ， 那 如 何 拥抱 变化 呢 ? 幸运 的 是 ， 设 计 模式 给 了 我 们 
指导 ， 专 家 们 首先 提出 了 6 大 设计 原则 ， 但 这 6 大 设计 原则 仅仅 是 一 系 
列 “ 口 号 ”， 真 正 付 诸 实施 还 需要 有 详尽 的 指导 方法 ， 于 是 23 种 设计 模 
式 出 现 了 。 


设计 模式 已 经 诞 近 20 年 了 ， 其 间 出 版 了 很 多 关于 它 的 经 典 若 作 ， 
相信 大 家 都 能 如 数 家 珍 。 尺 管 有 这 么 多 书 ， 工 作 5 年 了 还 不 知道 什么 是 


策略 模式 、 状 态 模式 、 责 任 链 模 式 的 程序 员 大 有 人 在 。 不 信 ? 你 找 个 
机 会 去 “虚心 "地 请 教 一 下 你 的 同事 ， 看 看 他 对 设计 模式 有 多 少 了 解 
不 要 告诉 我 要 翻 书 才 明 白 ! 设计 模式 不 是 工具 ， 它 是 软件 开发 的 哲 

学 ， 它 能 指导 你 如 何 去 设 计 一 个 优秀 的 架构 、 编 写 一 段 健壮 的 代码 、 
解决 一 个 复杂 的 需求 


因为 它 是 软件 行业 的 经 验 总 结 ， 因 此 它 具 有 更 广泛 的 适应 性 ， 不 
管 你 使 用 什么 编程 语言 ， 不 管 你 遇 到 什么 业务 类 型 ， 设 计 模 式 都 可 以 
目 由 地 “侵入 ”。 


因为 它 不 是 工具 ， 所 以 它 没 有 一 个 可 以 具体 测量 的 标尺 ， 完 全 以 
你 目 己 的 理解 为 准 ， 你 认为 目 己 多 了 解 它 ， 你 殉 有 可 能 产生 多 少 的 优 
秀 代 码 和 设计 。 


因为 它 是 指导 思想 ， 你 可 以 在 此 基础 上 自由 发 挥 ， 甚 至 是 自己 设 
计 出 一 套 设计 模式 。 


世界 上 最 难 的 事 有 两 件 : 一 是 让 人 心甘情愿 地 把 钱 掏 出 来 给 你 ， 
二 是 把 自己 的 思想 灌输 到 别人 的 脑子 里 。 设 计 模 式 就 属于 第 二 种 ， 它 
不 是 一 种 具体 的 技术 ， 不 像 Struts、Spring、Hibernate 等 框架 。 一 个 工 
具 用 久 了 可 以 熟 能 生 巧 ， 就 像 砌 墙 的 工人 一 样 ， 长 年 累 月 地 砌 场 ， 他 
也 知道 如 何 把 墙 砌 整齐 ， 如 何 多 快 好 省 地 干 活 ， 这 是 一 个 人 的 本 能 。 
我 们 把 Struts 用 得 很 汶 ， 把 Spring 用 得 很 顺手 ， 这 非常 好 ， 但 这 只 是 一 


个 合格 的 程序 员 应 该 具备 的 基本 能 力 ! 于 是 我 们 被 冠 以 代码 工人 
软件 行业 的 体力 劳动 者 。 


(Code Worker) 


如 果 你 通晓 了 这 23 种 设计 模式 束 不 同 了 ， 你 可 以 站 在 一 个 更 高 的 
层次 去 赏析 程序 代码 、 软 件 设 计 、 染 构 ， 完 成 从 代码 工人 到 架构 师 的 
申 变 。 注 意 ， 我 说 的 是 “通晓 ”， 别 告诉 我 你 把 23 种 设计 模式 的 含义 、 
适应 性 、 优 缺点 都 搞 清楚 了 就 是 通晓 。 错 了 ! 没有 工作 经 验 的 积累 是 
不 可 能 真正 理解 设计 模式 的 ， 这 殊 像 大 家 小 时 候 一 直 不 明日 为 什么 爸 
爸 妈 妈 要 工作 而 不 能 每 天 陪 目 己 玩 一 样 。 


据说 有 的 大 学 已 经 开 了 设计 模式 这 门 诗 ， 如 采 仅 仅 是 几 特 课 ， 让 
学 生 对 设计 模式 有 一 个 初步 的 了 解 ， 我 觉得 并 无 不 妥 ， 但 如 有 果 是 专门 
的 一 门 课程 ， 我 建议 取消 它 ! 因为 对 一 个 尚 无 项 目 开 发 经 验 的 学 生来 
说 ， 理 解 设 计 模 式 不 是 一 般 困 难 ， 而 是 非常 非常 困难 ! 之 前 没有 任何 
的 实战 经 验 ， 之 后 也 没有 可 以 立即 付 诸 实 践 的 场景 ， 这 样 能 理解 设计 
模式 吗 ? 


在 编写 本 书 之 前 ，23 种 设计 模式 我 都 用 过 ， 而 且 还 算 比 较 熟 练 ， 
但 是 当真 正 要 写 到 书 中 时 ， 感 觉 心 里 没 谱 儿 了 。 这 个 定义 是 这 样 的 
吗 ? 是 需要 用 抽象 类 还 是 应 该 用 接口 ? 为 什么 在 这 里 不 能 抽取 抽象 
呢 ? 为 什么 在 实际 项 目 中 这 个 模式 要 如 此 旷 化 ? 这 类 小 问题 有 时 候 很 
纠结 ， 需 要 花费 大 量 的 精力 和 时 间 去 分 析 和 确认 。 所 以 ， 在 写作 的 过 
程 中 我 有 过 很 多 忧虑 ， 担 心 书 中 会 有 太 多 瑕 狐 ， 这 种 忧虑 现在 仍然 存 


在 。 直 到 挫折 的 时 候 也 气 饿 过 ,但 古 我 坚信 一 句 话 :“ 开 马 没 有 回头 
箭 ， 回 头 即 是 空 ”， 既 然 已 经 开始 ， 束 一 定 要 圆满 完成 。 


第 2 版 与 第 1 版 的 区 别 


本 书 是 第 2 版 ， 在 写作 中 吸取 了 读者 对 上 一 版 的 许多 意见 和 建议 ， 
修订 了 一 些 代码 的 变量 、 类 、 方 法 名 称 ， 以 更 加 符合 目 然 语 言 ， 删 
了 部 分 有 和 争议 的 内 容 (如 单 例 模 式 的 垃圾 回收 问题 ， ;修改 了 一 些 常 
用 的 名 词 ， 确 保 与 编程 人 员 的 习惯 相 匹配 。 和 希望 通过 这 些 改进 ， 给 读 
者 提供 一 个 更 完美 的 设计 模式 盛 豆 ， 弥 补 上 一 版 中 的 诸多 不 足 。 


第 2 版 第 38 章 中 痢 增 了 4 种 新 的 设计 模式 : 对 象 池 模式 、 雇 工 模 
式 、 上 黑板 模式 、 空 指针 模式 。 这 些 模 式 是 我 们 在 实际 工作 中 经 常 遇 
到 ， 或 者 在 开源 代码 时 党 看 到 的 ， 但 是 我 们 却 没 有 升级 到 “ 模式 ”这 一 
理性 高 度 。 特 别 是 像 空 指针 模式 ， 我 们 在 编码 中 经 常会 遇 到 空 值 判 断 
问题 ， 但 我 们 没有 去 想 一 想 是 否 可 以 有 更 好 的 方式 解决 。 第 2 版 对 空 指 
针 模 式 进 行 了 讲解 ， 虽 然 简单 ， 但 相信 对 你 提升 编码 质量 有 很 大 的 帮 
助 。 


本 书 的 特色 


简单 、 通 俗 、 易 全 ， 但 又 不 肤浅 ， 这 是 本 书 的 最 大 特色 。 目 己 看 
过 的 技术 书 还 算 比 较 多 ， 很 痛恨 那 种 大 块头 的 巨著 ， 搁 家 里 当 枕头 都 
锁 得 太 硬 。 如 采 要 是 再 星 深 难 届 点 ， 那 根本 没 法 看 ， 看 起 来 实在 是 太 
累 。 设 计 模式 原本 就 是 理论 性 的 知识 ， 讲 解 的 难度 比较 大 ， 但 我 相信 
这 本 书 能 够 把 你 对 设计 模式 的 八 惧 一 要 而 光 。 不 信 ? 挑 几 页 先 看 看 ! 


我 的 理念 是 : 像 看 小 说 一 样 阅读 本 书 。 我 尽量 用 浅显 通俗 的 语言 
讲解 ， 尽 量 让 你 有 继续 看 下 去 的 和 欲望， 尽量 努力 让 你 有 兴趣 进入 设计 
模式 的 世界 ， 兴 趣 是 第 一 老师 嘛 ! 虽然 我 尽量 让 这 本 书 浅显 、 通 俗 、 
易 履 ， 但 并 不 代表 我 的 讲解 束 很 肤浅 。 每 个 设计 模式 讲解 完毕 之 后 ， 
我 都 附加 了 两 个 非常 精华 的 部 分 : 设计 模式 扩展 和 最 佳 实践 ， 这 是 俐 
压 箱底 的 技能 了 ， 为 了 博 君 一 看 ， 没 招 了 ， 拌 出 来 吧 ! 尤为 值得 一 提 
的 是 ， 本 书 还 有 设计 模式 PK 和 混 编 设计 模式 两 部 分 内 容 教 你 如 何 自 如 
地 去 运用 这 些 设计 模式 ， 这 是 当前 所 有 设计 模式 类 的 图 书 都 不 具备 
的 ， 连 最 权威 的 那 本 书 也 不 例外 。 


我 很 讨 大 技术 文章 中 夹 洒 着 的 那些 星 深 难民 的 文子 ， 特 别 是 一 堆 
又 一 堆 的 名 词 堆砌 ， 让 人 看 着 束 反 骨 。 但 是 为 了 学 习 技 术 ， 为 了 生 
存 ， 还 是 必须 看 下 去 。 国 内 的 技术 文档 ， 基 本 上 都 是 板 着 一 副 冷 面孔 
讲 技术 ， 为 什么 要 把 技术 弄 得 这 么 生硬 呢 ? 技术 也 有 它 幽 默 、 和 柔情 的 
一 面 ， 只 古 被 我 们 的 “ 孔 夫 子 们 ”掩盖 了 ， 能 用 萝卜 、 日 羔 这 种 寻 第 人 


都 熟悉 的 知识 来 讲解 原子 弹 理 论 的 人 ， 那 是 牛人 ， 我 佩服 这 样 的 人 。 
记 住 ， 用 一 扒 名 词 把 你 忽悠 晕 的 人 很 可 能 什么 都 不 全 


本 书 想 告 诉 你 的 是 ， 技 术 也 可 以 很 有 乐趣 ， 也 可 以 让 你 不 用 敏 着 
眉头 思考 ， 等 待 你 的 只 是 静 静 地 看 ， 慢 慢 地 思考 ， 本 书 的 内 容 会 润 物 
细 无 声 地 融入 你 的 思维 中 。 


本 书面 癌 的 读 着 


热爱 技术 并 且 讨 厌 枯燥 乏味 技术 文章 的 读者 都 可 以 看 本 书 ; 


你 是 程序 员 ， 没 问题 ， 本 书 能 够 让 你 写 出 更 加 高 效 、 优 雅 的 代 
码 ; 


你 是 架构 师 ， 那 更 好 ， 设 计 模 式 可 让 你 设计 出 健壮 、 稳 定 、 高 效 
的 系统 ， 并 且 自 动 地 预防 未 来 业务 变化 可 能 对 系统 带 来 的 影响 ; 


你 是 项 目 经 理 ， 也 OK， 设 计 模式 可 以 让 你 的 工期 大 大 缩短 ， 让 
你 的 项 目 团队 成 员 快速 地 理解 你 的 意 图 ， 最 终 的 成 末 束 是 优 质 的 项 
目 : 高 可 靠 性 、 高 稳定 性 、 高 效率 和 低 维 护 成 本 。 


如 何 阅 谈 本 书 


首 允 声明 ， 本 书 中 所 有 的 例子 都 是 用 Java 语 言 来 实现 的 ， 但 征 你 
可 以 随手 翻 翻 看 ， 基 本 上 能 保证 每 三 条 语句 一 个 注释 ， 可 以 说 是 在 用 
虽 们 的 母语 讲解 设计 模式 。 即 使 你 不 慌 Java 语 言 ， 也 没有 关系 ， 只 
知道 在 Java 中 双 和 斜 枉 VW/) 代表 注释 就 足够 了 ， 况 且 Java 如 此 强大 和 局 
行 ， 多 了 解 一 点 没有 坏处 。 类 图 看 不 懂 ? 没关系 ， 不 影响 你 理解 设计 
模式 ， 多 看 看 束 屏 了 ! 


如 有 果 你 还 没有 编程 经 答 ， 我 建议 你 把 它 当 做 小 说 来 看 ， 懂 行 的 看 
门道 ， 不 懂行 的 看 热闹 ， 这 里 的 热闹 足够 多 ， 够 你 看 一 塌 的 了 。 你 现 
在 能 看 懂 多 少 是 多 少 ， 不 懂 没 有 关系 ， 你 要 知道 ， 经 验 不 十 像 长 青春 
着 一 样 ， 说 长 吏 长 出 来 了 ， 它 是 需要 时 间 积 素 的 ， 需 要 你 用 心 去 感 
受 ， 然 后 才能 明白 为 什么 要 如 此 设计 。 


如 有 条 你 已 经 对 编程 有 感觉 了 (至 少 两 年 开发 经 验 ) ， 我 相信 你 都 
能 看 全 ， 但 能 * 懂 ?到 什么 程度 ， 吏 很 难说 了 ， 看 你 的 水 平 了 。 但 是 ， 
我 可 以 保证 ， 这 里 的 设计 模式 都 是 你 能 看 慌 的 ， 没 有 你 看 不 慌 的 ! 我 
建议 你 通读 这 本 书 ， 然 后 挑 门 你 最 得 意 的 编程 语言 ， 动 手写 吧 ! 给 目 
己 制定 一 个 计划 ， 每 天 编写 一 段 代码 ， 不 需要 太 多 ，200 行 足够 ， 时 不 
时 地 把 设计 模式 融入 你 的 代码 中 。 甫 管 是 什么 代码 ， 比 如 你 想 编写 一 
个 识别 美女 图 片 的 程序 ， 好 呀 ， 抓 紧 时 间 去 写 吧 ， 写 好 了 整 不 用 到 处 
看 美女 了 ， 程 序 一 跑 就 把 网 上 的 美女 图 片 都 抓 过 来 了 ， 牛 呀 ( 记 住 ， 


程序 写 好 了 要 分 享 给 我 ) 。 看 吧 ， 坚 持 下 去 ， 一 年 以 后 你 再 跟 你 的 同 
售 比 较 一 下 ， 那 差距 肯定 不 是 一 般 的 大 。 


如 果 你 是 资深 工程 师 、 架 构 师 、 技 术 顾 问 等 高 等 级 的 技术 人 员 ， 
那 我 告诉 你 ， 你 找 对 这 本 书 了 。 系 统 染 构 没 有 思路 ? 没有 问题 ， 看 看 
扩展 部 分 ， 它 会 开阔 你 的 思路 。 系 统 的 维护 成 本 居 高 不 下 ? 看 看 本 
书 ， 设 计 模 式 也 许 能 帮 你 省 点 银子 。 开 发 货源 无 法 保证 ? 设计 模式 能 
让 你 用 有 限 的 资源 〈 软 硬件 资源 和 人 力 资 源 ) 设计 出 一 个 优秀 的 系 
统 。 项 目 质 量 参差 不 章 ， 缺 陷 一 大 堆 ? 多 用 设计 模式 ， 它 会 给 你 意 想 
不 到 的 效果 。 给 人 讲课 没有 素材 ? 没 问 题 ， 本 书 中 的 素材 足以 让 你 启 


得 阵 阵 掌声 ! 


编程 是 一 门 忆 术 活 ， 我 有 一 个 同事 ， 能 把 类 图 男 成 一 个 小 马 怨 的 
形状 ， 天 才 呀 ! 作为 一 位 技术 人 员 ， 最 基本 的 品质 就 是 诚实 , “知之 为 
知之 ， 不 知 为 不 知 ， 是 知 也 ”， 目 己 不 懂 没 有 关系 ， 去 学 ， 学 无 止境 ， 
但 古 千 万 不 要 信 多 ， 这 抓 一 点 ， 那 挖 一 点 ， 好 像 什么 都 性 ， 其 实 什么 
都 不 刷 。 中 国 一 直 推 潜 复 合 型 人 才 ， 我 不 古 很 赞成 ， 因 为 这 对 年 轻 人 
来 说 是 一 个 误导 。 先 精 一 项 技术 ， 然 后 再 发 散 学 习 ， 移 点 后 面 才 是 正 
道 。 


记得 《武林 外 传 》 中 有 这 样 一 段 对 话 : 


1 于 市 二胡 ， 二 让 有 玖 * 


-= 境界 是 手中 无 思 ， 心 中 也 无 思 。 

体 驻 一 下 吧 ， 我 们 的 设计 模式 就 是 一 把 刀 ， 极 致 的 境界 束 是 心中 
无 设计 模式 ， 代 码 亦 无 设计 模式 一 一 设计 模式 随处 可 见 ， 俯 拾 儿 是 
已 经 融入 软件 设计 的 灵魂 中 ， 这 才 是 高 手中 的 高 手 ， 简 称 高 高 


哦 ， 最 最 重要 的 起 记 说 了 ， 请 把 附录 中 的 “23 种 设计 模式 附 图 ” 撕 
下 来 ， 贴 在 你 的 办 公 桌 前 ， 时 不 时 地 看 看 ， 也 让 老板 看 看 ， 咱 是 多 入 
地 用 心 ! 


赤 丁 书 沂 


乍 一 看 ， 书 名 和 内 容 狐 似 不 相符 呀 ， 其 实 不 然 ! 


在 我 们 的 常规 思维 中 ,“ 禅 ?应 该 是 很 高 深 的 东西 ， 只 可 意 会 ， 
可 言传 。 没 错 ， 禅 罕 也 是 如 此 说 。 禅 是 得 道 者 的 “ 情 ”， 坪 不 能 用 言语 
来 表达 的 ， 但 是 得 道 者 为 了 能 让 更 多 的 人 “ 悟 "， 就 必须 用 最 容易 让 人 
理解 的 文字 把 目 己 的 体会 表达 出 来 。 本 书 的 “禅定 作者 对 设计 模式 
的 “ 悟 ”"， 本 书 的 “ 形 ” 就 是 你 现在 看 到 的 这 些 极 其 简单 、 通 俗 、 吻 懂 的 
XT 


y 


至 此 ， 大 家 应 该 不 会 再 对 书 名 有 妖 谍 了 吧 ， 哩 嘿 。 


致谢 


本 书 第 1 版 的 写作 耗 时 7 个 月 ， 第 2 版 的 更 狐 又 伦 了 4 个 月 ， 可 以 说 
征 榨 干 了 海 绢 里 所 有 的 水 一 一 基本 上 能 用 的 时 间 都 用 上 了 “。 在 公交 车 
上 打 腹 稿 ， 干 过 ! 在 马桶 上 得 货 料 ， 干 过 ! 在 睡梦 中 思考 案例 ， 也 有 
忠 差 没有 走火 入 魔 了 ! 


过 


首先 ， 感 谢 杨 福 川 编辑 ， 没 有 他 的 汪 眼 ， 这 本 书 不 可 能 出 版 。 其 
次 ， 感 谢 妻 子 和 儿子 ， 每 天 下 班 回 到 家 ， 一 按 门 铃 ， 儿 子 束 在 里 面 
叫 : “我 来 开门 ， 我 来 开门 。” 儿 子 三 岁 ， 太 调皮 了， 他 不 睡觉 我 基本 
上 十 不 能 开 写 的 ， 我 一 旦 开始 写 东 西 ， 他 束 跑 过 来 问 : “爸爸 ， 你 在 干 
什么 呀 ”， 紧 接着 下 一 句 束 古 “ 和 爸爸 ， 你 陪 我 玩 "， 基 本 都 是 拿 我 当 玩 
具 ， 别 的 小 朋友 都 是 把 父亲 当 马 对 ， 他 却 不 ， 他 把 我 当 摩托 车 策 ， 还 
要 加 油 |]， 发 动 …... 小 家 伙 脚 太 重 了 ， 再 骑 摩 托 ， 非 被 他 踩 死 不 可 ! 


还 要 感谢 我 的 朋友 王 怠 ， 周 末 只 要 小 家 伙 在 家 ， 我 只 有 找 地 方 写 
书 的 份 儿 ， 王 怠 非 常 详 快 地 把 钥匙 给 我 ， 让 我 有 一 个 安静 的 地 方 写 
书 。 一 个 人 沉浸 在 自己 喜欢 的 世界 里 也 是 一 件 非常 注 福 的 事 。 


当然 ， 还 要 感谢 JavaEye 上 所 有 顶 帖 的 网 友 ， 没 有 你 们 的 支持 我 谍 
没有 写作 的 动力 ， 束 像 布 腊 神 话 中 的 巨人 安泰 失去 了 大 地 的 力量 一 
样 ， 是 你 们 的 回帖 让 我 觉得 不 孤单 ， 让 我 知道 我 不 是 一 个 人 在 战斗 ! 


最 后 ， 再 次 对 本 书 中 可 能 出 现 的 错误 表示 歉意 ， 真 诚 地 接受 大 家 
又 炸 ! 如 有 果 你 在 阅读 本 书 时 发 现 错误 或 有 问题 想 讨 论 ， 请 发 邮件 给 


第 一 部 分 “大 旗 不 择 ， 谁 敢 冲洗 
一 一 6 六 设计 原则 全 新 解 谈 


章 单一 职责 原则 
草 里 氏 奉 换 原则 
章 ”依赖 倒置 原则 
草 ”接口 隔离 原则 
草 ” 巡 米 特 法 则 


开 闭 原则 


第 1 章 单一 职 贡 原则 


1.1 我 是 “ 牛 ” 类 ， 我 可 以 担任 多 职 吗 


单一 职责 原则 的 英文 名 称 是 Single Responsibility Principle， 简 称 是 
SRP。 这 个 设计 原则 备 受 和 争议， 只 要 你 想 和 别人 争执 、 居 气 或 者 是 吵 
架 ， 这 个 原则 是 屡 试 不 碍 的 。 如 果 你 是 老大 ， 看 到 一 个 接口 或 类 是 这 
样 或 那样 设计 的 ， 你 就 问 一 句 : “你 设计 的 类 符合 SRP 原 则 吗 ? ” 保 准 对 
方 立马 “萎缩 ? 掉 ， 而 且 还 一 脸 崇 拜 地 看 着 你 ， 心 想 : “老大 确实 英明 ”。 
这 个 原则 存在 争议 之 处 在 哪里 昵 ? 就 是 对 职责 的 定义 ， 什 么 是 类 的 职 
责 ， 以 及 怎么 划分 类 的 职责 。 我 们 先 举 个 例子 来 说 明 什 么 是 单一 职责 
原则 。 


只 要 做 过 项 目 ， 肯 定 要 接触 到 用 户 、 机 构 、 角 色 管 理 这 些 模块 ， 
基本 上 使 用 的 都 是 RBAC 模 型 (Role-Based Access Control， 基 于 角色 的 
访问 控制 ， 通 过 分 配 和 取消 角色 来 完成 用 户 权限 的 授予 和 取消 ， 使 动 
作 主 体 (用 户 ) 与 资源 的 行为 权限 ) 分 离 ) ， 确 实 是 一 个 很 好 的 解 
决 办 法 。 我 们 这 里 要 讲 的 是 用 户 管理 、 修 改 用 户 的 信息 、 增 加 机 构 

(一 个 人 属于 多 个 机 构 ) 、 增 加 角色 等 ， 用 户 有 这 么 多 的 信息 和 行为 
要 维护 ， 我 们 就 把 这 些 写 到 一 个 接口 中 ， 都 是 用 户 管理 类 嘛 ， 我 们 先 
来 看 它 的 类 图 ， 如 图 1-1 所 示 。 


<<Interface>> 
IUserInfo 
gg 


Fvoid setUserID(String userID) 
+Strng getUserID() 

+void setPassword(Strmg password) 
+Strng getPassword() 

+vold setUserName(String userName) 


HStrng getUserName() 

+boolean changePassword(Strng oldPassword) 
+boolean deleteUser() 

+vold mapUser() 

+boolean addOrg( nt orgID) 

+boolean addRole(nt roleID ) 


Userlnfo 
| 


图 1-1 用 户 信息 维护 类 图 


太 Easy 的 类 图 了 ， 我 相信 ， 即 使 是 一 个 初级 的 程序 员 也 可 以 看 出 
这 个 接口 设计 得 有 问题 ， 用 户 的 属性 和 用 户 的 行为 没有 分 开 ， 这 是 一 
个 严重 的 错误 ! 这 个 接口 确实 设计 得 一 团 糟 ， 应 该 把 用 户 的 信息 抽取 
成 一 个 BO (Business Object， 业 务 对 象 ) ， 把 行为 抽取 成 一 个 Biz 
(Business Logic， 业 务 逻 辑 ) ， 按 照 这 个 思路 对 类 图 进行 修正 ， 如 图 


1-2 所 示 。 


<<nterface>> <<mnterface>> 
IUserBO IUserBiz 


+void setUserID(Strmg userID) Hboolean changePassword(...) 

tString getUserID() +boolean deleteUser(IUserBO userBO) 

tvoid setPassword(String password) +void mapUser(IUserBO userBO) 

tString getPassword() Hboolean addOrg(TUserBO userBO, int orgID) 


+void setUserName(String userName) tboolean addRole(IUserBO userBO, int roleID) 
+Strmg getUserName() : 


<<Interface>> 
IUserlinfio 


负责 用 户 的 行为 


负责 用 户 的 属性 


图 1-2 职责 划分 后 的 类 图 


重新 拆 封 成 两 个 接口 ，IUserBO 负 责 用 户 的 属性 ， 简 单 地 说 ， 
IUserBO 的 职责 就 是 收集 和 反馈 用 户 的 属性 信息 ; IUserBiz 负 责 用 户 的 
行为 ， 完 成 用 户 信息 的 维护 和 变更 。 各 位 可 能 要 说 了 ， 这 个 与 我 实际 
工作 中 用 到 的 User 类 还 是 有 差别 的 呀 ! 别 着 急 ， 我 们 先 来 看 一 看 分 拆 
成 两 个 接口 怎么 使 用 。OK， 我 们 现在 是 面向 接口 编程 ， 所 以 产生 了 这 
个 UserInfo 对 象 之 后 ， 当 然 可 以 把 它 当 IUserBO 接 口 使 用 。 也 可 以 当 
IUserBiz 接 口 使 用 ， 这 要 看 你 在 什么 地 方 使 用 了 。 要 获得 用 户 信 息 ， 就 
当 是 IUserBO 的 实现 类 ; 要 是 希望 维护 用 户 的 信息 ， 就 把 它 当 作 
IUserBiz 的 实现 类 就 成 了 ， 如 代码 清单 1-1 所 示 。 


代码 清单 1-1 分 清 职责 后 的 代码 示例 


IUSerInfo UserInfo = new UserInfol( ) ， 
// 我 要 赋值 了 ， 我 就 认为 它 是 一 个 纯粹 的 BO 
IUserBO userBO = (IUserBo)userInfo ， 
userBO.setPpassword("abc"); 

// 我 要 执行 动作 了 ， 我 就 认为 是 一 个 业务 逻辑 类 
IUserBiz userBiz = (IUserBiz)userIinfo; 
userBiz.deleteUser(); 


确实 可 以 如 此 ， 问 题 也 解决 了 ， 但 是 我 们 来 分 析 一 下 刚才 的 动 
作 ， 为 什么 要 把 一 个 接口 拆 分 成 两 个 昵 ? 其 实 ， 在 实际 的 使 用 中 ， 我 
们 更 倾向 于 使 用 两 个 不 同 的 类 或 接口 : 一 个 是 IUserBO， 一 个 是 
IUserBiz， 类 图 如 图 1-3 所 示 。 


<<Interface>> 
IUserBO 


<<Interface>> 
IUserBiz 


图 1-3 项 目 中 经 常 采用 的 SRP 类 图 


以 上 我 们 把 一 个 接口 拆 分 成 两 个 接口 的 动作 ， 整 古 依 赖 了 单一 职 
责 原则 ， 那 什么 是 单一 职责 原则 呢 ? 单一 职责 原则 的 定义 是 : 应 该 有 
且 仅 有 一 个 原因 引起 类 的 变更 。 


1.2 绝 杀 技 ， 打 破 你 的 传统 思维 


解释 到 这 里 ， 佑 计 你 已 经 很 不 悄 了 ,，“ 切 ! 这 么 简单 的 东西 还 要 
讲 ? ! ”好 ， 我 们 来 讲 点 复 洒 的 。SRP 的 原 话 解释 是: 


There should never be more than one reason for a class to change. 


这 人 句 话 初中 生 都 能 看 屏 ， 不 多 说 ， 但 是 看 慌 是 一 码 事 ， 实 施 束 古 
另外 一 码 事 了 。 上 面 讲 的 例子 很 好 理解 ， 在 实际 项 目 中 大 家 都 已 经 这 
么 做 了 ， 那 我 们 再 来 看 看 下 面 这 个 例子 是 否 好 理解 。 电 话 这 玩意 ， 是 
现代 人 都 离 不 了 ， 电 话 通话 的 时 候 有 4 个 过 程 发 生 : 拨号 、 通 话 、 回 
应 、 挂 机 ， 那 我 们 写 一 个 接口 ， 其 类 图 如 图 1-4 所 示 。 


<<imterface>> 
IPhone 


+vold dial(Strmg phone Number) 
+vold chat(Object o) 
+Vold hangup() 


图 1-4 电话 类 图 


我 不 是 有 和 意 要 冒犯 Phone 的 ， 同 名 纯 属 巧合 ， 我 们 来 看 一 个 这 个 过 
程 的 代码 ， 如 代码 清单 1-2 所 示 。 


代码 清单 1-2 电话 过 程 


public interface IPhone { 
// 拨 通电 话 
public void dial(String phoneNumber ) ; 
// 通 话 
public void chat(Object 0o); 
// 通 话 完毕 ， 挂 电话 

public void hangup(); 


实现 类 也 比较 商 单 ， 我 吏 不 再 写 了 ， 大 家 看 看 这 个 接口 有 没有 问 
题 ? 我 相信 大 部 分 的 读者 都 会 说 这 个 没有 问题 呀 ， 以 前 我 就 是 这 么 做 
的 呀 ， 某 某 书 上 也 是 这 么 写 的 呀 ， 还 有 什么 什么 的 源码 也 是 这 么 写 
的 ! 是 的 ， 这 个 接口 接近 于 完美 ， 看 清楚 了 ， 是 “接近 ”! 单一 职责 原 
则 要 求 一 个 接口 或 类 只 有 一 个 原因 引起 变化 ， 也 融 是 一 个 接口 或 类 只 
有 一 个 职责 ， 它 融 负 责 一 件 事 情 ， 看 看 上 面 的 接口 只 负责 一 件 事 情 
吗 ? 是 只 有 一 个 原因 引起 变化 吗 ? 好 像 不 是 


IPhone 这 个 接口 可 不 是 只 有 一 个 职 包含 了 两 个 职责 : 一 个 是 
协议 管理 ， 一 个 是 数据 传送 。 TS 法 实现 的 是 协议 管 
> 别 负责 拨号 接 通 和 挂机 ，chatO0 实 现 的 是 数据 的 传送 ， 把 我 们 说 
的 话 转换 成 模拟 信号 或 数字 信号 传递 到 对 方 ， 然 后 再 把 对 方 传递 过 来 
的 信号 还 原 成 我 们 听 得 懂 的 语言 。 我 们 可 以 这 样 考虑 这 个 问题 ， 协 议 
接 通 的 变化 会 引起 这 个 接口 或 实现 类 的 变化 吗 ? 会 的 ! 那 数据 传送 


( 想 想 看 ， 电 话 不 仅仅 可 以 通话 ， 还 可 以 上 网 ) 的 变化 会 引起 这 个 接 
口 或 实现 类 的 变化 吗 ? 会 的 ! 那 就 很 简单 了 ， 这 里 有 两 个 原因 都 引起 
了 类 的 变化 。 这 两 个 职责 会 相互 影响 吗 ? 电话 拨号 ， 我 只 要 能 接 通 就 
成 ， 志 管 生 电信 的 还 是 网 通 的 协议 ; 电话 连接 后 还 关心 传递 的 是 什么 
数据 吗 ? 通过 这 样 的 分 析 ， 我 们 发 现 类 图 上 的 IPhone 接 口 包 含 了 两 个 职 


责 ， 而 且 这 两 个 职 贡 的 变化 不 相互 影响 ， 那 束 考 虚 拆 分 成 两 个 接口 ， 
其 类 图 如 图 1-5 所 示 。 


<<interface>> <<interface>> 
IConnectionManager IDataTransfer 


= EE 二 
+void dial(String phone Number) +DataTransfer(IConnectionManager cm) 
Hvoid hangup() 


ConnectionManager DataTransfer 
| 一 
EE =w | | 


图 1-5 职 贡 分 明 的 电话 类 图 


<<Interface>> 
IDataTransfer 
[RE 


+DataTransferUConnectionManager cm) 


图 1-6 简 污 请 晰 、 职 贡 分 明 的 电话 类 网 


这 个 类 图 看 上 去 有 点 复杂 了 ， 完 全 满足 了 单一 职责 原则 的 要 求 ， 
每 个 接口 职责 分 明 ， 结 构 清 晰 ， 但 是 我 相信 你 在 设计 的 时 候 肯 定 不 会 
采用 这 种 方式 ， 一 个 手机 类 要 把 ConnectionManager 和 DataTransfer 组 合 
在 一 块 才能 使 用 。 组 合 是 一 种 强 耦 合 关系 ， 你 和 我 都 有 共同 的 生命 
期 ， 这 样 的 强硬 合 天 系 还 不 如 使 用 接口 实现 的 方式 呢 ， 而 且 还 增加 了 
类 的 复杂 性 ， 多 了 两 个 类 。 经 过 这 样 的 思考 后 ， 我 们 再 修改 一 下 类 
图 ， 如 图 1-6 所 示 。 


这 样 的 设计 才 是 完美 的 ， 一 个 类 实现 了 两 个 接口 ， 把 两 个 职责 融 
合 在 一 个 类 中 。 你 会 觉得 这 个 Phone 有 两 个 原因 引起 变化 了 呀 ， 是 的 ， 
但 是 别 筷 记 了 我 们 是 面 癌 接口 编程 ， 我 们 对 外 公布 的 是 接口 而 不 是 实 
现 类 。 而 且 ， 如 有 宁 真 要 实现 类 的 单一 职责 ， 这 个 吏 必 须 使 用 上 面 的 组 
合 模式 了 ， 这 会 引起 类 间 耦 合 过 重 、 类 的 数量 增加 等 问题 ， 人 为 地 增 
加 了 设计 的 复杂 性 。 


通过 上 面 的 例子 ， 我 们 来 总 结 一 下 单一 职 贡 原则 有 什么 好 处 : 


e 类 的 复杂 性 降低 ， 实 现 什么 职员 部 有 清晰 明确 的 定义 ; 


e 可 读 性 提高 ， 复 杂 性 降低 ， 那 当然 可 读 性 提高 了 ; 


e 可 维护 性 提高 ， 可 读 性 提高 ， 那 当然 更 容易 维护 了 ; 


e 变更 引起 的 风险 降低 ， 变 更 是 必 不 可 少 的 ， 如 有 果 接 口 的 单一 职责 
做 得 好 ， 一 个 接口 修改 只 对 相应 的 实现 类 有 影响 ， 对 其 他 的 接口 无 影 
响 ， 这 对 系统 的 扩展 性 、 维 护 性 都 有 非常 大 的 帮助 。 


看 过 电话 这 个 例子 后 ， 是 不 十 想 反 思 一 下 了 ， 我 以 前 的 设计 古 不 
征 有 氮 问 题 了 ? 不 ， 不 是 的 ， 不 要 怀疑 目 己 的 技术 能 力 ， 单 一 职责 原 
则 最 难 划分 的 束 是 职责 。 一 个 职责 一 个 接口 ， 但 问题 是 “职责 ?没有 一 
个 量化 的 标准 ， 一 个 类 到 捅 要 负责 那些 职责 ? 这 些 职责 该 怎么 细 化 ? 
细 化 后 是 否 都 要 有 一 个 接口 或 类 ? 这 些 都 需要 从 实际 的 项 目 去 考虑 ， 
从 功能 上 来 说 ， 定 义 一 个 IPhone 接 口 也 没有 错 ， 实 现 了 电话 的 功能 ， 而 
且 设 计 还 很 商 单 ， 仅 仅 一 个 接口 一 个 实现 类 ， 实 际 的 项 目 我 想 大 家 都 
会 这 么 设计 。 项 目 要 考虑 可 变 因 系 和 不 可 变 因 素 ， 以 及 相关 的 收益 成 
本 比率 ， 因 此 设计 一 个 IPhone 接 口 也 可 能 是 没有 错 的 。 但 是 ， 如 果 纯 
从 “学 完 ” 理 论 上 分 析 束 有 问题 了 ， 有 两 个 可 以 变化 的 原因 放 到 了 一 个 
接口 中 ， 这 束 为 以 后 的 变化 市 来 了 风险 。 如 采 以 后 模拟 电话 升级 到 数 


字 电 话 ， 我 们 提供 的 接口 IPhone 是 不 是 要 修改 了 ? 接口 修改 对 其 他 的 
Invoker 类 是 不 是 有 很 大 影响 ? 


注意 ”单一 职责 原则 提出 了 一 个 编写 程序 的 标准 ， 用 “职责 ”或 “ 变 
化 原因 ”来 衡量 接口 或 类 设计 得 是 否 优 民 ， 但 古 “ 职 责 * 和 “变化 原因 ”都 
古 不 可 度量 的 ， 因 项 目 而 异 ， 因 环境 而 异 。 


1.3 我 单纯 ， 所 以 我 快乐 


对 于 接口 ， 我 们 在 设计 的 时 候 一 定 要 做 到 单一 ， 但 是 对 于 实现 类 
束 需 要 多 方面 考虑 了 。 生 搬 便 套 单一 职责 原则 会 引起 类 的 剧 增 ， 给 维 
护 带 来 非常 多 的 麻烦 ， 而 且 过 分 细 分 类 的 职责 也 会 人 为 地 增加 系统 的 
复杂 性 。 本 来 一 个 类 可 以 实现 的 行为 硬 要 拆 成 两 个 类 ， 然 后 再 使 用 珍 
合 或 组 合 的 方式 耦合 在 一 起 ， 人 为 制造 了 系统 的 复杂 性 。 所 以 原则 是 
死 的 ， 人 是 活 的 ， 这 人 句 话 很 有 道理 。 


单一 职责 原则 很 难 在 项 目 中 得 到 体现 ， 非 党 难 ， 为 什么 ? 在 国 
内 ， 技 术 人 员 的 地 位 和 话语 权 都 比较 低 ， 因 此 在 项 目 中 需要 考虑 环 
境 ， 考 虑 工作 量 ， 考 虑 人 员 的 技术 水 平 ， 考 虑 硬件 的 资源 情况 ， 等 
等 ， 最 终 受 协 的 结果 是 经 营 违 到 单一 职责 原则 。 而 且 ， 我们 中华 文明 
束 有 很 多 属于 混合 型 的 产物 ， 比 如 筷子 ， 我 们 可 以 把 筑 子 当做 刀 来 使 
用 ， 分 割 食物 ， 还 可 以 当 又 使 用 ， 把 食物 从 盘子 中 移动 到 口中 。 而 在 
西方 的 文化 中 ， 刀 就 是 刀 ， 叉 就 是 义 ， 你 去 吃 西 餐 的 时 候 这 两 样 肯定 
都 和 十 有 的 ， 刀 了 吏 是 切割 食物 ， 又 吏 下 固定 食物 或 者 移动 食物 ， 分 工 很 
明晰 。 这 种 文化 的 差异 很 难 一 步 改 造 过 来 ， 但 是 我 相信 随 着 技术 的 深 
入 ， 单 一 职责 原则 必然 会 深入 到 项 目的 设计 中 ， 而 且 这 个 原则 征 那 么 
的 简单 ， 简 单 得 不 需要 我 们 更 加 深入 地 思考 ， 单 从 字面 上 大 家 都 应 该 


知道 是 什么 意思 ， 单 一 职责 嘛 ! 


单一 职责 适用 于 接口 、 类 ， 同 时 也 适用 于 方法 ， 什 么 意思 呢 ? 一 
个 方法 尽 可 能 做 一 件 事情 ， 比 如 一 个 方法 修改 用 户 密码 ， 不 要 把 这 个 


方法 放 到 “修改 用 户 信息 ”方法 中 ， 这 个 方法 的 颗粒 度 很 粗 ， 比 如 图 1-7 
中 所 示 的 方法 。 


<<Interface>> 
lIUserManager 


| 
+vold changeUser(IUserBO userBO, Strmg...changeOptions) 


图 1-7 一 个 方法 承担 多 个 职责 


在 IUserManager 中 定义 了 一 个 方法 changeUser， 根 据 传递 的 类 型 不 
同 ， 把 可 变 长 度 参 数 changeOptions 修 改 到 userBO 这 个 对 象 上 ， 并 调用 
持久 层 的 方法 保存 到 数据 库 中 。 在 我 的 项 目 组 中 ， 如 果 有 人 写 了 这 样 
一 个 方法 ， 我 不 管 他 写 了 多 少 程序 ， 伦 了 多 少 工夫 ， 一 律 重 写 ! 原因 
很 简单 : 方法 职责 不 清晰 ， 不 单一 ， 不 要 让 别人 猜测 这 个 方法 可 能 是 
用 来 处 理 什么 逻辑 的 。 比 较 好 的 设计 如 图 1-8 所 示 。 


通过 类 图 可 知 ， 如 果 要 修改 用 户 名 称 ， 束 调用 changeUserName 方 
法 ， 要 修改 家 庭 地 址 ， 就 调用 changeHomeAddress 方 法 ， 要 修改 单位 电 
话 ， 吏 调用 changeOfficeTel 方 法 。 每 个 方法 的 职员 非 第 清晰 明确 ， 不 仅 
开发 简单 ， 而 且 日 后 的 维护 也 非常 容易 ， 大 家 可 以 逐渐 养 成 这 样 的 习 


惯 。 


<<Interface>> 
IUserManager 


+Vold changeUserName(String newUserName) 
+vold changeHomeAddress(Strmg newHomeAddress) 
+void changeOfficeTel(Strng teINumber) 


图 1-8 一 个 方法 承担 一 个 职 贡 


所 以 ， 如 条 对 接口 、 类 、 方 法 使 用 了 单一 职责 原则 ， 那 么 快乐 的 
就 不 仅仅 是 你 了 ， 还 有 你 的 项 目 组 成 员 ， 大 家 可 以 轻松 而 又 愉快 地 进 
行 开发 ， 还 有 你 的 老板 ， 减 少 了 因为 变更 引起 的 工作 量 ,减少 了 无 请 
的 人 员 和 资金 消耗 。 当 然 ， 最 快乐 的 也 许 就 是 你 了 ， 因 为 加 官 晋 姻 可 
能 等 着 你 哟 ! 


1.4 最 佳 实践 


阅读 到 这 里 ， 可 能 有 人 会 问 我 ， 你 写 的 是 类 的 设计 原则 吗 ? 你 通 
篇 都 在 说 接口 的 单一 职责 ， 类 的 单一 职 贡 你 都 违背 了 呀 ! 呵呵 ， 这 个 
还 真是 的 ， 我 的 本 意 古 想 把 这 个 原则 讲 清楚 ， 类 的 单一 职 贡 嘛 ， 

民 和 出 单 ， 但 当 我 回头 写 的 时 候 ， 发 觉 并 不 是 这 么 回 事 ， 翻 看 了 以 前 的 
一 些 设计 和 代码 ， 基 本 上 拿 得 出 手 的 类 设计 都 是 与 单一 职责 相 违 育 
的 。 静 下 心 来 回忆 ， 发 觉 每 一 个 类 这 样 设计 都 症 有 原因 的 。 我 得 阅 了 
Wikipedia、OODesign 等 几 个 网 站 ， 专 家 和 我 也 有 类 似 的 经 验 ， 基 本 上 
类 的 单一 职责 都 用 了 类 似 的 一 句 话 来 说 "This is sometimes hard to 

see"， 这 人 句 话 翻译 过 来 整 是 “这 个 有 了 时候 很 难说 *”。 是 的 ， 类 的 单一 职 
责 确实 受 非 常 多 因素 的 制约 ， 纯 理论 地 来 讲 ， 这 个 原则 是 非常 优秀 
的 ， 但 是 现实 有 现实 的 难处 ， 你 必须 去 考虑 项 目 工期 、 成 本 、 人 员 技 
术 水 平 、 硬 件 情况 、 网 络 情况 甚至 有 时 候 还 要 考虑 政府 政策 、 垄 断 协 

等 因素 。 比 如 ，2004 年 我 束 做 过 一 个 项 目 ， 做 加 密 处 理 的 ， 甲 方 就 
甩 过 来 一 句 话 ， 你 什么 都 不 用 管 ， 调 用 这 个 API 融 可 以 了 ， 不 用 考虑 
什么 传输 协议 、 异 第 处 理 、 安 全 连接 和 等。 所以， 我 们 就 直接 使 用 了 JNI 
与 加 密 三 商 提 供 的 API 通 信 ， 什 么 单一 职责 原则 ， 根 本 束 不 用 考虑 ， 
因为 对 方 不 公布 通信 接口 和 弄 稼 判断 。 


询 Si 


对 于 单一 职责 原则 ， 我 的 建议 是 接口 一 定 要 做 到 单一 职责 ， 类 的 
设计 尽量 做 到 只 有 一 个 原因 引起 变化 。 


第 2 章 ”里 氏 殖 换 原 出 


2.1 爱 恨 纠 唤 的 父子 关系 


在 面 同 对 象 的 语言 中 ， 继 承 是 必 不 可 少 的 、 非 第 优秀 的 语言 机 
制 ， 它 有 如 下 优点 : 


e 代码 共 译 ， 减 少 创建 类 的 工作 量 ， 每 个 子 类 都 拥有 父 类 的 方法 
和 属性 ; 


e 提高 代码 的 重用 性 ; 


e 于 类 可 以 形似 父 类 ， 但 又 异 于 父 类 ,“ 龙 生 龙 ， 风 生 风 ， 老 鼠 生 
来 会 打 洞 ?是 说 子 拥 有 父 的 “种 ”>, “世界 上 没有 两 片 完 全 相同 的 叶子” 征 
指明 子 与 父 的 不 同 ; 


e 提高 代码 的 可 扩展 性 ， 实 现 父 类 的 方法 就 可 以 “为 所 欲 为 "了 ， 
君 不 见 很 多 开源 框架 的 扩展 接口 都 是 通过 继承 父 类 来 完成 的 ; 


e 提高 产品 或 项 目的 开放 性 。 


目 然 界 的 所 有 事物 都 是 优点 和 缺点 并 存 的 ， 即 使 是 鸡 蝇 ， 有 时候 
也 能 挑 出 骨头 来 ， 继 承 的 缺点 如 下 : 


e 继承 是 侵入 性 的 。 只 要 继承 ， 豆 必须 拥有 父 类 的 所 有 属性 和 方 
法 ; 

e 降低 代码 的 灵活 性 。 子 类 必须 拥有 父 类 的 属性 和 方法 ， 让 子 类 
目 由 的 世界 中 多 了 些 约束 ; 


e 增强 了 耘 合 性 。 当 父 类 的 常量 、 变 量 和 方法 被 修改 时 ， 需 要 考 
虑 子 类 的 修改 ， 而 且 在 缺乏 规范 的 环境 下 ， 这 种 修改 可 能 带 来 非常 粳 
糕 的 结果 一 一 大 段 的 代码 需要 重 构 。 


Java 使 用 extends 关 键 字 来 实现 继承 ， 它 采用 了 单一 继承 的 规则 ， 
C++ 则 采用 了 多 重 继承 的 规则 ， 一 个 子 类 可 以 继承 多 个 父 类 。 从 整体 
上 来 看 ， 利 大 于 兹 ， 怎 么 才能 让 “ 利 ” 的 因素 发 挥 最 大 的 作用 ， 同 时 减 
少 “ 弊 " 囊 来 的 麻烦 呢 ? 解决 方案 是 引入 里 氏 替 换 原 则 (Liskov 
Substitution Principle，LSP) ， 什 么 是 里 氏 奉 换 原 则 呢 ? 它 有 两 种 定 


e 第 一 种 定义 ， 也 是 最 正宗 的 定义 : If for each object ol oftype S 
there is an object o2 of type T such that for all programs P defined in terms 
of T,the behavior of P is unchanged when ol is substituted for o2 then S is a 
subtype of 工 〈 如 果 对 每 一 个 类 型 为 $ 的 对 象 o1， 都 有 类 型 为 T 的 对 象 
02， 使 得 以 T 定 义 的 所 有 程序 P 在 所 有 的 对 象 ol 都 代 换 成 o2 时 ， 程 序 P 
的 行为 没有 发 生变 化 ， 那 么 类 型 $ 是 类 型 T 的 子 类 型 。) 


大 二 一 


e 第 二 种 定义 : Functions that use pointers or references to base 


classes must be able to use objects of derived classes without knowing it. 


(所 有 引用 基 类 的 地 方 必须 能 透明 地 使 用 其 子 类 的 对 象 。) 


第 二 个 定义 古 最 清晰 明确 的 ， 通 俗 点 讲 ， 只 要 父 类 能 出 现 的 地 方 
子 类 束 可 以 出 现 ， 而 且 蔡 换 为 子 类 也 不 会 产生 任何 错误 或 异 前 ， 使 用 
者 可 能 根本 束 不 需要 知道 是 父 类 还 是 子 类 。 但 是 ， 反 过 来 殉 不 行 了 ， 
有 子 类 出 现 的 地 方 ， 父 类 未 必 束 能 适应 。 


2.2 纠纷 不 断 ， 规 则 压制 


里 氏 蔡 换 原 则 为 良好 的 继承 定义 了 一 个 规范 ， 一 句 简单 的 定义 包 
含 了 4 层 含义 。 

1. 子 类 必须 完全 实现 父 类 的 方法 

我 们 在 做 系统 设计 时 ， 经 常会 定义 一 个 接口 或 抽象 类 ， 然 后 编码 
实现 ， 调 用 类 则 直接 传 入 接口 或 抽象 类 ， 其 实 这 里 已 经 使 用 了 里 氏 替 


换 原 则 。 我 们 举 个 例子 来 说 明 这 个 原则 ， 大 家 都 打 过 CS 吧 ， 非 常 经 典 
的 FPS 类 游戏 ， 我 们 来 描述 一 下 里 面 用 到 的 枪 ， 类 图 如 图 2-1 所 示 。 


E = 


-AbstractGun gun 
+void setGun(AbstractGun _gun) +void shoot() 
+void KillEnemy() 


_ Handgun | 
手枪 | 步 检 | 机 枪 


图 2-1 CS 游戏 中 的 枪支 类 图 


枪 的 主要 职责 十 射击 ， 如 何 射 击 在 各 个 具体 的 于 类 中 定义 ， 手枪 
征 单 发 射程 比较 近 ， 步 枪 威力 大 射程 远 ， 机 枪 用 于 扫射 。 在 士兵 类 中 
定义 了 一 个 方法 killEnemy， 使 用 枪 来 杀 敌 人 ， 有 具体 使 用 什么 枪 来 杀 政 
人 ， 调 用 的 时 候 才 知道 ，AbstractGun 类 的 源 程序 如 代码 清单 2-1 所 示 。 


代码 清单 2-1 枪 文 的 抽象 类 


public abstract class AbstractGun { 
// 枪 用 来 干什么 的 ? 杀 政 1 


public abstract void shoot(); 


手枪 、 步 枪 、 机 枪 的 实现 类 如 代码 清单 2-2 所 示 。 


代码 清单 2-2 手枪 、 步 枪 、 机 枪 的 实现 类 


public class Handgun extends AbstractGun { 
// 手 枪 的 特点 是 携带 方便 ， 射程 短 
@Override 
public void shoot() { 
System.out.printlin(" 手 枪 射击 ,.."); 


public class Rifle extends AbstractGunt{ 
// 步 枪 的 特点 是 射程 远 ， 威 力 大 
public void shoot(){ 
System.out.printlin(" 步 枪 射击 ,.."); 


public class MachineGun extends AbstractGunt{ 
public void shoot(){ 
System.out.printlLn(" 机 枪 扫 射 , . .")， 


有 了 枪支 ， 还 要 有 人 能够 使 用 这 些 枪支 的 士兵 ， 其 源 程序 如 代码 清 
单 2-3 所 示 。 


代码 清单 2-3 士兵 的 实现 类 


public class Soldier { 

// 定 义士 兵 的 枪支 

private AbstractGun gun; 

// 给 士兵 一 支 枪 

public void setGun(AbstractGun _gun)t{ 
this.gun = _gun; 


} 

public void killEnemy(){ 
System.out.println(" 士 兵 开 始 杀 天 人...,")， 
gun.shoot( ); 


定义 士兵 使 用 枪 来 杀 敌 ， 但 是 这 把 枪 是 抽象 的 ， 有 具体 是 手枪 还 是 
步枪 需要 在 上 战场 前 (也 就 是 场景 中 ) 前 通过 setGun 方 法 确定 。 场 景 类 
Client 的 源 代码 如 代码 清单 2-4 所 示 。 


代码 清单 2-4 场景 


public class Client { 
public static void main(String[] args) { 
// 产 生 三 毛 这 个 士兵 
Soldier SanMao = new Soldier(); 
// 给 三 毛 一 文 枪 
sanMao.setGun(new Rifle()); 
sanMao.killEnemy(); 


有 人 ， 有 枪 ， 也 有 场景 ， 运 行 结 琳 如 下 所 示 。 


士兵 开始 杀 敌 人... 


步枪 射击 .… 


在 这 个 程序 中 ， 我 们 给 三 毛 这 个 士兵 一 把 步枪 ， 然 后 就 开始 杀 敌 
了 。 如 果 三 毛 要 使 用 机 枪 ， 当 然 也 可 以 ， 直 接 把 sanMao.setGun(new 
Rifle()) 修 改 为 sanMao.setGun(new MachineGun()) 即 可 ， 在 编写 程序 时 
Solider 士 兵 类 根本 就 不 用 知道 是 哪个 型 号 的 枪 ( 子 类 ) 被 传 入 。 


注意 “在 类 中 调用 其 他 类 时 务必 要 使 用 父 类 或 接口 ， 如 果 不 能 使 
用 父 类 或 接口 ， 则 说 明 类 的 设计 已 经 违背 了 LSP 原 则 。 


我 们 再 来 想 一 想 ， 如 采 我 们 有 一 个 玩具 手枪 ， 该 如 何 定 义 呢 ? 我 
们 先 在 类 图 2-1 上 增加 一 个 类 ToyGun， 然 后 继承 于 AbstractGun 类 ， 修 改 
后 的 类 图 如 图 2-2 所 示 。 


-AbstractGun gun ee 


Hvoid setGun(AbstractGun gun) 
Hvoid killEnemy() 


| 
+vold shoot() 


Machine Gun 


ToyGun 
| 
EE 


图 2-2 枪支 类 图 


首先 我 们 想 ， 玩 具 枪 是 不 能 用 来 射击 的 ， 杀 不 死人 的 ， 这 个 不 应 
该 写 在 shoot 方 法 中 。 新 增加 的 ToyGun 的 源 代码 如 代码 清单 2-5 所 示 。 


代码 清单 2-5 玩具 枪 源 代码 


public class ToyGun extends AbstractGun { 


// 玩 具 枪 是 不 能 射击 的 ， 但 是 编译 器 又 要 求实 现 这 个 方法 ， 怎 么 办 ? 虚构 一 个 


JI 
@Override 
public void shoot() { 
// 玩 具 枪 不 能 射击 ， 这 个 方法 就 不 实现 ] 
} 


由 于 引入 了 新 的 子 类， 场景 类 中 也 使 用 了 该 类 ，Client 稍 作 修 改 ， 
源 代码 如 代码 清单 2-6 所 示 。 


代码 清单 2-6 场景 


public class Client { 
public static void main(String[] args) { 
// 产 生 三 毛 这 个 士 ; 
Soldier SanMao = new Soldier(); 
sanMao.setGun(new ToyGun( )); 
sanMao.killEnemy(); 


把 玩具 枪 传递 给 三 毛 用 来 杀 敌 ， 代 码 运行 结 来 如 下 所 示 : 


士兵 开始 杀 栈 人 .… 


坏 了 ， 士 兵 拿 着 玩具 枪 来 杀 政 人 ， 射 不 出 子弹 呀 ! 如 有 果 在 CS 游戏 
中 有 这 种 事情 发 生 ， 那 你 就 等 着 锌 人 爆 头 吧 ， 然 后 看 着 自己 姜 惨 地 倒 
地 。 在 这 种 情况 下 ， 我 们 发 现 业 务 调 用 类 已 经 出 现 了 问题 ， 正 贡 的 业 
务 逻 辑 已 经 不 能 运行 ， 那 怎么 办 ? 好 办 ， 有 两 种 解决 办 法 : 


e 在 Soldier 类 中 增加 instanceof 的 判断 ， 如 采 是 玩具 枪 ， 束 不 用 来 杀 
敌人 。 这 个 方法 可 以 解决 问题 ,但 是 你 要 知道 ， 在 程序 中 ， 每 增加 一 
个 类 ， 所 有 与 这 个 父 类 有 关系 的 类 都 必须 修改 ， 你 觉得 可 行 吗 ? 如 果 
你 的 产品 出 现 了 这 个 问题 ， 因 为 修正 了 这 样 一 个 Bug， 就 要 求 所 有 与 这 
个 父 类 有 关系 的 类 都 增加 一 个 判断 ， 客 户 非 跳 起 来 跟 你 干 架 不 可 ! 你 
还 想 要 客户 忠诚 于 你 吗 ? 显然 ， 这 个 方案 被 否定 了 。 


e ToyGun 脱 离 继 承 ， 建 立 一 个 独立 的 父 类 ， 为 了 实现 代码 复 用 ， 
可 以 与 AbastractGun 建 立 关 联 委托 关系 ， 如 图 2-3 所 示 。 


Ww 
. 


-AbstractGun gun a 


VY 有 
AbstractGun 


+void shoot() 


tvoid setGun( AbstractGun _ gun) 
+vold killEnemy!) 


Machine Gun 


图 2-3 玩具 枪 与 真实 枪 分 离 的 类 图 


例如 ， 可 以 在 AbstractToy 中 声明 将 声音 、 形 状 都 委托 给 
AbstractGun 处 理 ， 仿 真 枪 嘛 ， 形 状 和 声音 都 要 和 真实 的 枪 一 样 了 ， 然 
后 两 个 基 类 下 的 子 类 目 由 延展 ， 互 不 影响 。 


在 Java 的 基础 知识 中 部会 讲 到 继承 ，Java 的 三 大 特征 嘛 ， 封 泛 、 继 
承 、 多 仿 。 继 承 束 是 告诉 你 拥有 父 类 的 方法 和 属性 ， 然 后 你 整 可 以 重 
写 父 类 的 方法 。 按 照 继承 原则 ， 我 们 上 面 的 玩具 枪 继承 AbstractGun 是 
绝对 没有 问题 的 ， 玩 具 枪 也 是 枪 嘛 ,但 是 在 具体 应 用 场景 中 就 要 考虑 
下 面 这 个 问题 了 : 子 类 是 否 能 够 完整 地 实现 父 类 的 业务 ， 否 则 束 会 出 
现 像 上 面 的 拿 枪杀 敌人 时 却 发 现 是 把 玩具 枪 的 笑话 。 


注意 《如 果子 类 不 能 完整 地 实现 父 类 的 方法 ， 或 者 父 类 的 某 些 方 
法 在 子 类 中 已 经 发 生 “ 栈 变 ”>， 则 建议 断 开 父子 继承 关系 ， 采 用 依赖 、 


案 集 、 组 合 等 天 系 代 珍 继承 。 


2. 于 类 可 以 有 目 己 的 个 性 


子 类 当然 可 以 有 自己 的 行为 和 外 观 了 ， 也 就 是 方法 和 属性 ， 那 这 
里 为 什么 要 再 提 呢 ?是 因为 里 氏 奉 换 原 则 可 以 正春 用 ,但 是 不 能 反 过 
来 用 。 在 子 类 出 现 的 地 方 ， 父 类 未 必 束 可 以 胜任 。 还 是 以 刚才 的 天 于 
枪 文 的 例子 为 例 ， 步 检 有 几 个 比较 “响亮 2 的 型 号 ， 比 如 AK47、AUG 狙 
击 步枪 等 ， 把 这 两 个 型 号 的 枪 引 入 后 的 Rifle 于 类 图 如 图 2-4 所 示 。 


-AUG aug 


+void setGun(AUG aug) 
+void kilEnemy() 


| | 
Hyold zoomOut() 


图 2-4 增加 AK47 和 AUG 后 的 Rifle 子 类 图 


很 简单 ，AUG 继 承 了 Rifle 类 ， 狙 击 手 (Snipper) 则 直接 使 用 AUG 
狙击 步枪 ， 源 代码 如 代码 清单 2-7 所 示 。 


代码 清单 2-7 AUG 狙 击 枪 源码 代码 


public class AUG extends Rifle { 
// 狙 击 枪 都 携 带 一 个 精准 的 望远镜 
public void zoomOut(){ 
System.out.println(" 通 过 望远镜 察看 敌人 ...")，; 


} 
public void shoot(){ 
System.out.println("AUG 射 击 ..."); 


有 和 狙击 枪 就 有 狙击 手 ， 狙 击 手 类 的 源 代码 如 代码 清单 2-8 所 示 。 


代码 清单 2-8 AUG 和 狙击 手 类 的 源码 代码 


public class Snipper { 
public void killEnemy(AUG aug)t{ 
// 首 先 看 看 敌人 的 情况 ， 别 杀 死 敌人 ， 目 己 也 被 人 干掉 
aug .zoomOut( ) ， 


// 开 始 射击 


aug,Shoot( ) ， 


狙击 手 ， 为 什么 叫 Snipper? Snipe 翻 译 过 来 就 是 顶 ， 就 是 “ 裔 蚌 相 
争 ， 汐 人 得 利 ” 中 的 那 只 鸟 ， 英 国 贵 族 到 印度 打猎 ， 发 现 这 个 酮 很 陪 
明 ， 人 一 上 靠近 束 飞 走 了 ， 没 办 法 就 开始 伪装 、 远 程 精准 射击 ， 于 是 乎 
Snipper 吏 诞生 了 。 


狙击 手 使 用 狙击 枪 来 杀 死 履 人 ， 业 务 场景 Client 类 的 源 代 码 如 代码 
清单 2-9 所 示 。 


代码 清单 2-9 狙击 手 使 用 AUG 杀 死 天 人 


public class Client { 
public static void main(String[] args) { 
// 产 生 三 毛 这 个 狙击 手 
Snipper SanMao = new Snipper(); 
sanMao. setRifle(new AUG()); 
sanMao.killEnemy(); 


狙击 手 使 用 G3 杀 死敌 人 人， 运行 结 采 如 下 所 示 : 


通过 望远镜 察看 敌人 .… 


AUG 射 击 .… 


在 这 里 ， 系 统 直 接 调 用 了 了 于 类 ， 和 狙击 手 是 很 依赖 枪 坟 的 ， 别 说 换 
一 个 型 号 的 枪 了 ， 融 是 换 一 个 同型 号 的 枪 也 会 影响 射击 ， 所 以 这 里 融 


直接 把 子 类 传递 了 进来 。 这 个 时 候 ， 我 们 能 不 能 直接 使 用 父 类 传递 进 
来 呢 ? 修改 一 下 Client 类 ， 如 代码 清单 2-10 所 示 。 


代码 清单 2-10 使 用 父 类 作为 参数 


public class Client { 
public static void main(String[] args) { 
// 产 生 三 毛 这 个 狙击 手 
Snipper SanMao = new Snipper(); 
sanMao.setRifle( (AUG) (new Rifle( ))); 
sanMao.killEnemy(); 


显示 是 不 行 的 ， 会 在 运行 期 抛 出 java.lang.ClassCastException 异 
常 ， 这 也 是 大 家 经 常 说 的 向 下 转型 “downcast) 是 不 安全 的 ， 从 里 氏 替 
换 原 则 来 看 ， 惑 是 有 子 类 出 现 的 地 方 父 类 未 必 就 可 以 出 现 。 


3. 履 次 或 实现 父 类 的 方法 时 输入 参数 可 以 被 放大 


方法 中 的 输入 参数 称 为 前 置 条 件 ， 这 是 什么 意思 呢 ? 大 家 做 过 Web 
Service 开 发 就 应 该 知道 有 一 个 “契约 优先 ”的 原则 ， 也 就 是 先 定义 出 
WSDL 接 口 ， 制 定好 双方 的 开发 协议 ， 然 后 再 各 目 实现 。 里 氏 蔡 换 原则 
也 要 求 制定 一 个 揣 约 ， 吏 是 父 类 或 接口 ， 这 种 设计 方法 也 叫做 Design 
by Contract (小 约 设计 ) ， 与 里 氏 蔡 换 原 则 有 着 异曲同工 之 妙 。 契 约 制 
定 了 ， 也 了 束 同 时 制定 了 前 置 条 件 和 后 置 条 件 ， 前 置 条 件 丈 是 你 要 让 我 
执行 ， 就 必须 满足 我 的 条 件 ， 后 置 条 件 就 是 我 执行 完了 需要 反馈 ， 标 


准 是 什么 。 这 个 比较 难 理解 ， 我 们 来 看 一 个 例子 ， 我 们 先 定 义 一 个 
Father 类 ， 如 代码 清单 2-11 所 示 。 


代码 清单 2-11 Father 类 源 代 码 


public class Father { 
public Collection doSomething(HashMap map)t{ 
System,out,.println(" 父 类 被 执行 ,. ."); 
return map,vValues( ) ， 


这 个 类 非 销 简单 ， 束 是 把 HashMap 转 换 为 Collection 集 合 类 型 ， 然 
后 再 定义 一 个 子 类 ， 源 代码 如 代码 清单 2-12 所 示 。 


代码 清单 2-12 子 类 源 代码 


public class Son extends Father { 
// 放 大 输入 参数 类 型 
public Collection doSomething(Map map){ 
System.out .println(" 子 类 被 执行 ,..")， 
return map.values( ) ， 


你 加 个 @Override 试 试看 ， 会 报错 的 ， 为 什么 呢 ? 方法 名 虽然 相 
同 ， 但 方法 的 输入 参数 不 同 ， 融 不 是 履 写 ， 那 这 是 什么 呢 ? 是 重 载 
(Overload) ! 不 用 大 惊 小 怪 的 ， 不 在 一 个 类 就 不 能 是 重 载 了 ? 继承 是 
什么 意思 ， 子 类 拥有 父 类 的 所 有 属性 和 方法 ， 方 法 名 相同 ， 输 入 参数 
类 型 又 不 相同 ， 当 然 古 重 载 『。 父 类 和 了 于 类 部 已 经 声明 了 了， 场景 类 的 
调用 如 代码 清单 2-13 所 示 。 


代码 清单 2-13 场景 类 源 代码 


public class Client { 
public static void invoker(){ 
// 父 类 存在 的 地 方 ， 子 类 就 应 该 能 够 存在 
Father f = new Father()， 
HashMap map = new HashMap(); 


f.doSsomething(map); 


} 
public static void main(String[] args) { 
invoker( ); 


} 


代码 运行 后 的 结果 如 下 所 示 : 
父 类 被 执行 .… 
根据 里 氏 替 换 原则 ， 父 类 出 现 的 地 方 子 类 就 可 以 出 现 ， 如 代码 清 
单 2-14 所 示 。 
代码 清单 2-14 子 类 替换 父 类 后 的 源 代码 


public class Client { 
public static void invoker(){ 
// 父 类 存在 的 地 方 ， 子 类 就 应 该 能 够 存在 
Son f =new Son(); 
HashMap map = new HashMap(); 


f.doSsomething(map); 


} 
public static void main(String[] args) { 
invoker( ); 


} 
} 
运行 结果 还 是 一 样 ， 看 明白 是 怎么 回 事 了 吗 ? 父 类 方法 的 输入 参 


数 是 HashMap 类 型 ， 子 类 的 输入 参数 是 Map 类 型 ， 也 束 是 说 子 类 的 输入 


参数 类 型 的 范围 扩大 了 ， 子 类 代替 父 类 传递 到 调用 者 中 ， 子 类 的 方法 
永远 都 不 会 被 执行 。 这 是 正确 的 ， 如 果 你 想 让 子 类 的 方法 运行 ， 束 必 
须 覆 写 父 类 的 方法 。 大 家 可 以 这 样 想 ， 在 一 个 Invoker 类 中 关联 了 一 个 
父 关 ， 调 用 了 一 个 父 类 的 方法 ， 子 类 可 以 覆 写 这 个 方法 ， 也 可 以 重 载 
这 个 方法 ， 前 提 是 要 扩大 这 个 前 置 条 件 ， 就 古 输入 参数 的 类 型 贺 于 父 
类 的 类 型 履 盖 范围 。 这 样 说 可 能 比较 难 理解 ， 我 们 再 反 过 来 想 一 下 ， 

如 琳 Father 类 的 输入 参数 类 型 宽 于 了 类 的 输入 参数 类 型 ， 会 出 现 什么 问 
题 呢 ? 会 出 现 父 类 存在 的 地 方 ， 子 类 束 末 必 可 以 存在 ， 因 为 一 旦 把 于 
类 作为 参数 传 入 ， 调 用 车 束 很 可 能 进入 于 类 的 方法 范畴 。 我 们 把 上 面 
的 例子 修改 一 下 ， 扩 大 父 类 的 前 置 条 件 ， 源 代码 如 代码 清单 2-15 所 示 。 


代码 清单 2-15 父 类 的 前 置 条 件 较 大 


public class Father { 
public Collection doSomething(Map map){ 
System,out,.println(" 父 类 被 执行 ,. ."); 
return map,vValues( ) ， 


} 


把 父 类 的 前 置 条 件 修改 为 Map 类 型 ， 我 们 再 修改 一 下 子 类 方法 的 输 
入 参数 ， 相 对 父 类 缩小 输入 参数 的 类 型 范围 ， 也 束 古 缩小 前 置 条 件 ， 
源 代码 如 代码 清早 2-16 所 示 。 


代码 清单 2-16 子 类 的 前 置 条 件 较 小 


public class Son extends Father { 
// 缩 小 输入 参数 范围 
public Collection doSomething(HashMap map)t{ 


System,out ,println(" 子 类 被 执行 , . ."); 
return map.values(); 


在 父 类 的 前 置 条 件 大 于 子 类 的 前 置 条 件 的 情况 下 ， 业 务 场景 的 源 
代码 如 代码 清单 2-17 所 示 。 


代码 清单 2-17 子 类 的 前 置 条 件 较 小 


public class Client { 
public static void invoker(){ 
// 有 父 类 的 地 方 就 有 子 类 
Father f= new Father(); 
HashMap map = new HashMap(); 
f.dosomething(map); 


} 

public static void main(String[] args) { 
invoker( ); 

} 


代码 运行 结案 如 下 所 示 : 
父 类 被 执行 … 
那 我 们 再 把 里 氏 称 换 原则 引入 进来 会 有 什么 问题 ? 有 父 类 的 地 方 


子 类 就 可 以 使 用 ， 好 ， 我 们 把 这 个 Client 类 修改 一 下 ， 源 代码 如 代码 清 
单 2-18 所 示 。 


代码 清单 2-18 采用 里 氏 蔡 换 原则 后 的 业务 场景 : 


public class Client { 
public static void invoker(){ 
// 有 父 类 的 地 方 束 有 子 类 
Son f =new Son(); 
HashMap map = new HashMap(); 


f.doSomething(map ) ， 


} 

public static void main(String[] args) { 
invoker( ); 

} 


代码 运行 后 的 结果 如 下 所 示 : 
子 类 被 执行.. 


完 重 了 吧 ? ! 了 于 类 在 没有 和 窗 写 父 类 的 方法 的 前 提 下 ， 了 于 类 方法 被 
执行 了 ， 这 会 引起 业务 逻辑 混乱 ， 因 为 在 实际 应 用 中 父 类 一 般 都 是 抽 
象 类 ， 子 类 是 实现 类 ， 你 传递 一 个 这 样 的 实现 类 就 会 “ 息 曲 "了 父 类 的 
意图 ， 引 起 一 堆 意 想不到 的 业务 逻辑 寓 乱 ， 所 以 子 类 中 方法 的 前 置 条 
件 必 须 与 超 类 中 被 履 写 的 方法 的 前 置 条 件 相同 或 者 更 宽松 。 


4. 履 写 或 实现 父 类 的 方法 时 输出 结果 可 以 家 缩小 


这 是 什么 意思 呢 ， 父 类 的 一 个 方法 的 返回 值 是 一 个 类 型 T， 子 类 的 
相同 方法 ( 重 载 或 履 写 ) 的 返回 值 为 S， 那 么 里 氏 替 换 原 则 就 要 求 S 必 
须 小 于 等 于 T， 也 就 是 说 ， 要 么 S 和 T 是 同一 个 类 型 ， 要 么 S 是 I 的 子 
类 ， 为 什么 呢 ? 分 两 种 情况 ， 如 果 是 履 写 ， 父 类 和 子 类 的 同名 方法 的 
输入 参数 是 相同 的 ， 两 个 方法 的 范围 值 $ 小 于 等 于 T[， 这 是 履 写 的 要 
求 ， 这 才 是 重 中 之 重 ， 子 类 和 履 写 父 类 的 方法 ， 天 经 地 义 。 如 果 是 重 
载 ， 则 要 求 方法 的 输入 参数 类 型 或 数量 不 相同 ， 在 里 氏 替 换 原 则 要 求 
下 ， 就 是 子 类 的 输入 参数 宽 于 或 等 于 父 类 的 输入 参数 ， 也 就 是 说 你 写 
的 这 个 方法 是 不 会 被 调用 的 ， 参考 上 面 讲 的 前 置 条 件 。 


采用 里 氏 蔡 换 原则 的 目的 就 是 增强 程序 的 健壮 性 ， 版 本 升级 时 也 
可 以 保持 非常 好 的 兼容 性 。 即 使 增加 子 类 ， 原 有 的 子 类 还 可 以 继续 运 
行 。 在 实际 项 目 中 ， 每 个 子 类 对 应 不 同 的 业务 信义 ， 使 用 父 类 作为 参 
数 ， 传 递 不 同 的 子 类 完成 不 同 的 业务 逻辑 ， 非 党 完美 ! 


2.3 最 佳 实践 


在 项 目 中 ， 采 用 里 氏 替 换 原 则 时 ， 尽 量 避 免 子 类 的 “个 性 ”， 一 旦 
子 类 有 “个 性 ”， 这 个 子 类 和 父 类 之 间 的 关系 就 很 难 调 和 了 ， 把 子 类 当 
做 父 类 使 用 ， 子 类 的 “个 性 ”被 抹杀 一 一 委 届 了 点 ， 把 子 类 单独 作为 一 
个 业务 来 使 用 ， 则 会 让 代码 间 的 耦合 关系 变 得 扑朔迷离 一 缺乏 类 替 
换 的 标准 。 


第 3 草 ”依赖 倒置 原则 


3.1 依赖 倒置 原则 的 定义 


依赖 倒置 原则 (Dependence Inversion Principle,DIP) 这 个 名 字 看 
着 有 点 别扭 , “依赖 * 还 “倒置 "， 这 到 压 是 什么 意思 ? 依赖 倒置 原则 的 
原始 定义 是 : 


High level modules should not depend upon low level modules.Both 
should depend upon abstractions.Abstractions should not depend upon 


details.Details should depend upon abstractions. 
翻译 过 来 ， 包 含 三 层 合 义 : 
e 高 层 模 块 不 应 该 依赖 低层 模块 ， 两 者 都 应 该 依赖 其 抽象 ; 
e 抽象 不 应 该 依赖 细节 


e 细 帮 应 该 依赖 抽象 。 


高 层 模 块 和 低层 模块 容易 理解 ， 每 一 个 逻辑 的 实现 都 是 由 原子 远 
辑 组 成 的 ， 不 可 分 割 的 原子 逻辑 束 是 低层 模块 ， 原 子 逻 辑 的 再 组 逆 吏 
苹 噩 层 模块 。 那 什么 是 抽象 ? 什么 又 是 细 世 昵 ? 在 Java 语 言 中 ， 抽 和 象 


就 是 指 接口 或 抽象 类 ， 两 者 都 是 不 能 直接 被 实例 化 的 ; 细 区 就 是 实现 
类 ， 实 现 接 口 或 继承 抽象 类 而 产生 的 类 就 是 细节 ， 其 特点 就 是 可 以 直 
接 被 实例 化 ， 也 束 是 可 以 加 上 一 个 关键 字 new 产 生 一 个 对 象 。 依 赖 倒 
置 原则 在 Java 语 言 中 的 表现 就 十: 


e 模块 间 的 依赖 通过 抽象 发 生 ， 实 现 类 之 间 不 发 生 直接 的 依赖 关 
系 ， 其 依赖 关系 是 通过 接口 或 抽象 类 产生 的 ; 


e 接口 或 抽象 类 不 依赖 于 实现 类 ; 


e 实现 类 依赖 接口 或 抽象 类 。 


更 加 精简 的 定义 就 是 “面向 接口 编程 "OOD (Object-Oriented 
Design， 面 向 对 象 设计 ) 的 精髓 之 一 。 


3.2 言 而 无 信 ， 你 太 需 要 契约 


采用 依赖 倒置 原则 可 以 减少 类 间 的 耦合 性 ， 提 高 系统 的 稳定 性 ， 
降低 并 行 开发 引起 的 风险 ， 提 高 代码 的 可 读 性 和 可 维护 性 。 


证 明 一 个 定理 旦 否 正 确 ， 有 两 种 音 用 的 方法 : 一 种 是 根据 提出 的 
论题 ， 经 过 一 番 论 证 ， 推 出 和 定理 相同 的 结论 ， 这 有 是 顺 推 证 法 ;还 有 
一 种 羡 诈 先 假设 提出 的 命题 是 伪 命 题 ， 然 后 推导 出 一 个 欧 恋 、 与 已 知 
条 件 互 不 的 结论 ， 这 是 反 证 法 。 我 们 今天 束 用 反 证 法 来 证 明 依 赖 倒置 
原则 是 多 么 优秀 和 伟大 ! 


论题 : 依赖 倒置 原则 可 以 减少 类 间 的 耦合 性 ， 提 高 系统 的 稳定 
性 ， 降 低 并 行 开发 引起 的 风险 ， 提 高 代码 的 可 读 性 和 可 维护 性 。 


反 论 题 : 不 使 用 依赖 倒置 原则 也 可 以 减少 类 间 的 耦合 性 ， 提 高 系 
统 的 稳定 性 ， 降 低 并 行 开发 引起 的 风险 ， 提 高 代码 的 可 读 性 和 可 维护 
性 。 


我 们 通过 一 个 例子 来 说 明 反 论题 是 不 成 立 的 。 现 在 的 汽车 越 来 越 
便宜 了 ， 一 个 卫生 间 的 造价 欧 可 以 天 到 一 辆 不 错 的 汽车 ， 有 汽车 束 必 
然 有 有 人 来 芍 驶 ， 司 机 车 驶 奔驰 车 的 类 图 如 图 3-1 所 示 。 


Benz 


Driver 


+vold driver(Benz benz) 


+Vold run() 


Client 


图 3-1 司机 和 驶 奔驰 车 类 图 


奔驰 车 可 以 提供 一 个 方法 run， 代 表 车 辆 运行 ， 实 现 过 程 如 代码 清 
单 3-1 所 示 。 


代码 清单 3-1 司机 源 代 码 


public class Driver { 
// 司 机 的 主要 职责 就 是 芍 驶 汽车 
public void drive(Benz benz ){ 
benz.run(); 
} 


司机 通过 调用 奔驰 车 的 run 方 法 开动 奔驰 车 ， 其 源 代码 如 代码 清单 


3-2 所 示 。 


代码 清单 3-2 奔驰 车 源 代码 


public class Benz { 
// 汽 车 肯定 会 跑 
public void run()t{ 
System.out .println(" 奔 驰 汽 车 开始 运行 .. ."); 


有 车 ， 有 司机 ， 在 Client 场 景 类 产生 相应 的 对 象 ， 其 源 代 码 如 代码 
清单 3-3 所 示 。 


代码 清单 3-3 场景 类 源 代 人 码 


public class Client { 
public static void main(String[] args) { 
Driver zhangSan = new Driver(); 
Benz benz = new Benz(); 
// 张 三 开 奔 驰 车 
zhangSan.drive(benz); 


通过 以 上 的 代码 ， 完 成 了 司机 开动 奔驰 车 的 场景 ， 到 目前 为 止 ， 
这 个 司机 开 奔 驰 车 的 项 目 没 有 任何 问题 。 我 们 解说 “危难 时 刻 见 真 
情 ”， 我 们 把 这 人 句 话 移植 到 技术 上 就 成 了 “变更 才 显 真 功夫 ”*"， 业 务 需 求 
变更 永 无 休止 ， 技 术 前 进 吏 永 无 止境 ， 在 发 生变 更 时 才能 发 觉 我 们 的 
设计 或 程序 是 否 是 松 耦 合 。 我 们 在 一 段 貌 似 头 石 的 程序 上 加 上 一 块 小 
石头 : 张 三 司机 不 仅 要 开 奔 驰 车 ， 还 要 开 宇 蕊 车 ， 叉 该 上 怎么 实现 呢 ? 
磋 烦 出 来 了 ， 那 好 ， 我 们 走 一 步 古 一 步 ， 我 们 先 把 宝 号 车 产生 出 来 ， 
实现 过 程 如 代码 清单 3-4 所 示 。 


代码 清单 3-4 宝马 车 源 代码 


public class BMW { 
// 宝 马车 当然 也 可 以 开动 了 
public void run(){ 
System.out.println(" 宝 马 汽车 开始 运行 .. .")，) 


宇 蕊 车 也 产生 了 ,但 是 我 们 却 没 有 办 法 让 张 三 开 动 起 来 ， 为 什 
么 ? 张 三 没 有 开动 军马 车 的 方法 呀 ! 一 个 拿 有 C 芍 照 的 司机 竟然 只 能 
奔驰 车 而 不 能 开 宝马 车 ， 这 也 太 不 合理 了 ! 在 现实 世界 都 不 允许 存在 
这 种 情况 ， 何 况 程 序 还 是 对 现实 世界 的 抽象 ， 我 们 的 设计 出 现 了 问 
题 : 司机 类 和 奔驰 车 类 之 间 是 紧 籼 合 的 关系 ， 其 导致 的 结 来 就 古 系统 
的 可 维护 性 大 大 降低 ， 可 读 性 降低 ， 两 个 相似 的 类 需要 阅读 两 个 文 
件 ， 你 乐意 吗 ? 还 有 稳定 性 ， 什 么 是 稳定 性 ? 固化 的 、 健 壮 的 才 有 是 稳 
定 的 ， 这 里 只 是 增加 了 一 个 车 类 束 需 要 修改 司机 类 ， 这 不 是 稳定 性 ， 
这 是 易 变性 。 被 依赖 者 的 变更 竟然 让 依赖 者 来 承担 修改 的 成 本 ， 这 样 
的 依赖 关系 谁 肯 承担 ! 证 明 到 这 里 ， 我 们 已 经 知道 反 论题 已 经 部 分 不 
成 立 了 。 


注意 ”设计 是 否 具备 稳定 性 ， 只 要 适当 地 “ 松 松 土 "， 观 察 “ 设 计 的 
蓝图 ”是否 还 可 以 芷 壮 地 成 长 束 可 以 得 出 结论 ， 稳 定性 较 高 的 设计 ， 在 
周围 环境 频 迷 变化 的 时 候 ， 依 然 可 以 做 到 "我 目 妇 然 不 动 ”。 


我 们 继续 证 明 ，“ 减 少 并 行 开发 引起 的 风险 *"， 什 么 是 并 行 开发 的 
风险 ? 并 行 开 发 最 大 的 风险 就 是 风险 扩散 ， 本 来 只 是 一 段 程序 的 错误 
或 异 币 ， 逐 步 波及 一 个 功能 ， 一 个 模块 ， 甚 至 到 最 后 毁坏 了 整个 项 
目 。 为 什么 并 行 开发 束 有 这 样 的 风险 呢 ? 一 个 团队 ，20 个 开发 人 员 ， 


各 人 人 负责 不 同 的 功能 模块 ， 甲 负责 汽车 类 的 建造 ， 乙 负责 司机 类 的 建 
造 ， 在 甲 没有 完成 的 情况 下 ， 乙 十 不 能 完全 地 编写 代码 的 ， 缺 少 汽 芋 
类 ， 编 译 器 根本 就 不 会 让 你 通过 ! 在 缺少 Benz 类 的 情况 下 ，Driver 类 能 
编译 吗 ? 更 不 要 说 是 单元 测试 了 ! 在 这 种 不 使 用 依赖 倒置 原则 的 环境 
中 ， 所 有 的 开发 工作 都 是 “单线 程 " 的 ， 甲 做 完 ， 乙 再 做 ， 然 后 是 丙 继 
续 .……. 这 在 20 世 纪 90 年 代 “* 个 人 英雄 主义 ”编程 模式 中 还 是 比较 适用 
的 ， 一 个 人 完成 所 有 的 代码 工作 。 但 在 现在 的 大 中 型 项 目 中 已 经 是 完 
全 不 能 胜任 了 ， 一 个 项 目 是 一 个 团队 协作 的 结 有 末 ， 一 个 “英雄 ”再 牛 也 
不 可 能 了 解 所 有 的 业务 和 所 有 的 技术 ， 要 协作 吏 要 并 行 开 发 ， 要 并 行 
开发 束 要 解决 模块 之 间 的 项 目 依赖 关系 ， 那 然后 呢 ? 依赖 倒置 原则 融 
隆重 出 场 了 ! 


根据 以 上 证 明 ， 如 果 不 使 用 依赖 倒置 原则 束 会 加 重 类 间 的 耦合 
性 ， 降 低 系统 的 稳定 性 ， 增 加 并 行 开 发 引起 的 风险 ， 降 低 代 码 的 可 读 
性 和 可 维护 性 。 承 接 上 面 的 例子 ， 引 入 依赖 倒置 原则 后 的 类 图 如 图 3-2 
有 所 示 * 


<<interface>> 
IDriver 


+Vold driver(ICar car) 


人 
| 


图 3-2 引入 依赖 倒置 原则 后 的 类 图 


建立 两 个 接口 : IDriver 和 ICar， 分 别 定 义 了 司机 和 汽车 的 各 个 职 
能 ， 司 机 就 是 芍 驶 汽车 ， 必 须 实现 drive() 方 法 ， 其 实现 过 程 如 代码 清单 
3-5 所 示 。 


代码 清单 3-5 司机 接口 


public interface IDriver { 
// 是 司机 束 应 该 会 鸭 驶 汽车 


public void drive(ICar car ) ; 


接口 只 是 一 个 抽象 化 的 概念 ， 是 对 一 类 事物 的 最 抽象 描述 ， 有 具体 
的 实现 代码 由 相应 的 实现 类 来 完成 ，Driver 实 现 类 如 代码 清单 3-6 所 
代码 清单 3-6 司机 类 的 实现 


public class Driver Tn ements IDrivert{ 


// 司 机 的 主要 职责 就 是 驾驶 汽车 


public void drive(ICar car)t{ 
car.run(); 
} 


在 IDriver 中 ， 通 过 传 入 ICar 接 口 实现 了 抽象 之 间 的 依赖 关系 ， 
Driver 实 现 类 也 传 入 了 ICar 接 口 ， 至 于 到 底 是 哪个 型 号 的 Car， 需 要 在 高 
层 模 块 中 声明 。 


ICar 及 其 两 个 实现 类 的 实现 过 程 如 代码 清单 3-7 所 示 。 


代码 清单 3-7 汽车 接口 及 两 个 实现 类 


public interface ICar { 
// 是 汽车 就 应 该 能 跑 
public void run(); 


public class Benz implements ICart{ 
// 汽 车 肯定 会 跑 
public void run(){ 
System.out .println(" 奔 驰 汽车 开始 运行 .. .")，) 


public class BMW implements ICart{ 
// 宝 马车 当然 也 可 以 开动 了 
public void run()t{ 
System.out.println(" 宝 马 汽 车 开始 运行 ...")， 


在 业务 场景 中 ， 我 们 贯彻 “抽象 不 应 该 依赖 细节 ”， 也 就 是 我 们 认 
为 抽象 (ICar 接 口 ) 不 依赖 BPMW 和 Benz 两 个 实现 类 (细节 ) ， 因 此 在 
高 层次 的 模块 中 应 用 都 是 抽象 ，Client 的 实现 过 程 如 代码 清单 3-8 所 示 。 


代码 清单 3-8 业务 场景 


public class Client { 
public static void main(String[] args) { 
IDriver zhangSan = new Driver(); 

ICar benz = new Benz(); 
// 张 三 开 奔 驰 车 


zhangSan.drive(benz); 


Client 属 于 高 层 业 务 逻 辑 ， 它 对 低层 模块 的 依赖 都 建立 在 抽象 上 ， 
zhangSan 的 表面 类 型 是 IDriver，Benz 的 表面 类 型 是 ICar， 也 许 你 要 问 ， 
在 这 个 高 层 模块 中 也 调用 到 了 低层 模块 ， 比 如 new Driver() 和 new Benz() 
等 ， 如 何 解释 ? 确实 如 此 ，zhangSan 的 表面 类 型 是 IDriver， 是 一 个 接 
口 ， 是 抽象 的 、 非 实体 化 的 ， 在 其 后 的 所 有 操作 中 ，zhangSan 都 是 以 
IDriver 类 型 进行 操作 ， 屏 蔽 了 细节 对 抽象 的 影响 。 当 然 ， 张 三 如 果 要 
开 宝 马车 ， 也 很 容易 ， 我 们 只 要 修改 业务 场景 类 就 可 以 ， 实 现 过 程 如 
代码 清单 3-9 所 示 。 


代码 清单 3-9 张 三 营 驶 宝 蕊 车 的 实现 过 程 


public class Client { 
public static void main(String[] args) { 
IDriver zhangSan = new Driver(); 

ICar bmw = new BMW(); 
// 张 三 开 奔 驰 车 


zhangSan.drive(bmw); 


在 新 增加 低层 模块 时 ， 只 修改 了 业务 场景 类 ， 也 就 是 高 层 模块 ， 
对 其 他 低层 模块 如 Driver 类 不 需要 做 任何 修改 ， 业 务 就 可 以 运行 ， 
把 “变更 ”引起 的 风险 扩散 降 到 最 低 。 


注意 ”在 Java 中 ， 只 要 定义 变量 就 必然 要 有 类 型 ， 一 个 变量 可 以 
有 两 种 类 型 : 表面 类 型 和 实际 类 型 ， 表 面 类 型 是 在 定义 的 时 候 赋 予 的 
类 型 ， 实 际 类 型 是 对 象 的 类 型 ， 如 zhangSan 的 表面 类 型 是 IDriver， 实 际 


类 型 是 Driver 。 


我 们 再 来 思考 依赖 倒置 对 并 行 开发 的 影 啊 。 两 个 类 之 间 有 依赖 天 
系 ， 只 要 制定 出 两 者 之 间 的 接口 (或 抽象 类 ) 就 可 以 独立 开发 了 ， 而 
且 项 目 之 间 的 单元 测试 也 可 以 独立 地 运行 ,而 TDD (Test-Driven 
Development， 测 试 驱动 开发 ) 开发 模式 就 是 依赖 倒置 原则 的 最 高 级 应 
用 。 我 们 继续 回顾 上 面 司机 敬 驶 汽车 的 例子 ， 甲 程序 员 人 负责 IDriver 的 
开发 ， 乙 程序 员 人 负责 ICar 的 开发 ， 两 个 开发 人 员 只 要 制定 好 了 接口 束 可 
以 独立 地 开发 了 ， 甲 开发 进度 比较 快 ， 完 成 了 IDriver 以 及 相关 的 实现 
类 Driver 的 开发 工作 ， 而 乙 程序 员 滞 后 开发 ， 那 甲 是 否 可 以 进行 单元 测 
试 呢 ? 答案 是 可 以 ， 我 们 引入 一 个 JMock 工 具 ， 其 最 基本 的 功能 是 根据 
抽象 虚拟 一 个 对 象 进行 测试 ， 测 试 类 如 代码 清单 3-10 所 示 。 


代码 清单 3-10 测试 类 


public class DriverTest extends TestCaset{ 

Mockery context = new JUnit4Mockery(); 

@Test 

public void testDriver() { 
// 根 据 接口 虚拟 一 个 对 象 
final ICar car = context.mock(ICar.class); 
IDriver driver = new Driver(); 
// 内 部 类 


context.checking(new Expectations(){t{ 


oneof (car).run(); 


/ 
driver.drive(car); 


从 这 一 点 来 看 ， 两 个 相互 依赖 的 对 象 可 以 分 别 进行 开发 ， 孤 立地 
进行 单元 测试 ， 进 而 保证 并 行 开发 的 效率 和 质量 ，TDD 开 发 的 精 散 不 
束 在 这 里 吗 ? 测试 驱动 开发 ， 先 写 好 单元 测试 类 ， 然 后 再 写实 现 类 ， 
这 对 提高 代码 的 质量 有 非常 大 的 帮助 ， 特 别 适合 研发 类 项 目 或 在 项 目 
成 员 整 体 水 平 比较 低 的 情况 下 采用 。 


抽象 是 对 实现 的 约束 ， 对 依赖 者 而 言 ， 也 是 一 种 小 约 ， 不 仅仅 约 
束 自 己 ， 还 同时 约束 自己 与 外 部 的 关系 ， 其 目的 是 保证 所 有 的 细节 不 
脱离 契约 的 范畴 ， 确 保 约 束 双方 按照 既定 的 帆 约 (抽象 ， 共 同 发 展 ， 
只 要 抽象 这 根基 线 在 ， 细 市 束 脱 离 不 了 这 个 圈 圈 ， 始 终 让 你 的 对 象 做 
到 *“ 言 必 信 ， 行 必 采 ”。 


3.3 依赖 的 三 种 写法 


依赖 是 可 以 传递 的 ，A 对 和 象 依赖 B 对 象 ，B 又 依赖 C，C 又 依赖 
D..….. 生 生 不 轧 ， 依 赖 不 止 ， 记 住 一 点 : 只 要 做 到 抽象 依赖 ， 即 使 是 
多 层 的 依赖 传递 也 无 所 县 惧 ! 


对 象 的 依赖 关系 有 三 种 方式 来 传递 ， 如 下 所 示 。 
1. 构 造 国 数 传递 依赖 对 象 


在 类 中 通过 构造 函数 声明 依赖 对 象 ， 按 照 依赖 注入 的 说 法 ， 这 种 
方式 叫做 构造 函数 注入 ， 按 照 这 种 方式 的 注入 ，IDriver 和 Driver 的 程 
序 修改 后 如 代码 清单 3-11 所 示 。 


代码 清单 3-11 构造 钞 数 传递 依赖 对 象 


public interface IDriver { 
// 是 司机 就 应 该 会 区 驶 汽车 


public void drive(); 


public class Driver implements IDrivert{ 
private ICar car; 
// 构 造 函 数 注入 
public Driver(ICar _car){ 
this.car = _car; 


} 

// 司 机 的 主要 职责 束 是 区 驶 汽车 

public void drive(){ 
this.car.run( ); 

} 


2.Setter 方 法 传递 依赖 对 象 


在 抽象 中 设置 Setter 方 法 声明 依赖 和 关系， 依照 依赖 注入 的 说 法 ， 这 
是 Setter 依 赖 注入 ， 按 照 这 种 方式 的 注入 ，IDriver 和 Driver 的 程序 修改 
后 如 代码 清单 3-12 所 示 。 


代码 清单 3-12 Setter 依 赖 注 入 


public interface IDriver { 
// 车 辆 型 号 
public void setCar(ICar car); 
// 是 司机 就 应 该 会 萄 驶 汽车 
public void drive( ); 


} 
public class Driver implements IDrivert{ 
private ICar car; 
public void setCar(ICar car)t{ 
this.car = car; 


} 

// 司 机 的 主要 职责 就 是 驾驶 汽车 

public void drivel( ){ 
this.car.run( ); 

} 


3. 接 口 声明 依赖 对 象 


在 接口 的 方法 中 声明 依赖 对 象 ，3.2 节 的 例子 就 采用 了 接口 声明 依 
赖 的 方式 ， 该 方法 也 叫做 接口 注入 。 


3.4 和 最 佳 实践 


依赖 倒置 原则 的 本 质 就 是 通过 抽象 (接口 或 抽象 类 ) 使 各 个 类 或 
模块 的 实现 彼此 独立 ， 不 互相 影响 ， 实 现 模块 间 的 松 耦 合 ， 我 们 怎么 
在 项 目 中 使 用 这 个 规则 呢 ? 只 要 遵循 以 下 的 几 个 规则 束 可 以 : 


e 每 个 类 尽量 都 有 接口 或 抽象 类 ， 或 者 抽象 类 和 接口 两 者 部 具备 


这 是 依赖 倒置 的 基本 要 求 ， 接 口 和 抽象 类 都 是 属于 抽象 的 ， 有 了 
抽象 才 可 能 依赖 倒置 。 


变量 的 表面 类 型 尽量 是 接口 或 者 是 抽象 类 


很 多 书 上 说 变量 的 类 型 一 定 要 是 接口 或 者 是 抽象 类 ， 这 个 有 点 绝 
对 化 了 ， 比 如 一 个 工具 类 ，xxxUtils 一 般 是 不 需要 接口 或 是 抽象 类 的 。 
还 有 ， 如 果 你 要 使 用 类 的 clone 方 法 ， 束 必须 使 用 实现 类 ， 这 个 是 JDK 
提供 的 一 个 规范 。 


e 任何 类 都 不 应 该 从 具体 类 派生 


如 宁 一 个 项 目 处 于 开发 状态 ， 确 实 不 应 该 有 从 具体 类 派生 出 子 类 
的 情况 ， 但 这 也 不 是 绝对 的 ， 因 为 人 都 是 会 犯错 误 的 ， 有 时 设计 缺陷 
征 在 所 难免 的 ， 因 此 只 要 不 超过 两 讨 的 继承 都 是 可 以 忍受 的 。 特 别 是 


负责 项 目 维护 的 同志 ， 基 本 上 可 以 不 考虑 这 个 规则 ， 为 什么 ? 维护 工 
作 基 本 上 都 古 进行 扩展 开发 ， 修 复 行 为 ， 通 过 一 个 继承 关系 ， 禾 写 一 
个 方法 就 可 以 修正 一 个 很 大 的 Bug， 何 必 去 继承 最 高 的 基 类 呢 ? ( 当 
然 这 种 情况 尽量 发 生 在 不 其 了 解 父 类 或 者 无 法 获得 父 类 代码 的 情况 
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e 尺 量 不 要 和 窗 写 基 类 的 方法 


如 有 果 基 类 是 一 个 抽象 类 ， 而 且 这 个 方法 已 经 实现 了 ， 子 类 尽量 不 
要 禾 写 。 类 间 依 赖 的 是 抽象 ， 履 写 了 抽象 方法 ， 对 依赖 的 稳定 性 会 产 


生 一 定 的 影响 。 
e 结合 里 氏 芋 换 原 则 使 用 


在 第 2 章 中 我 们 讲解 了 里 氏 替 换 原 则 ， 父 类 出 现 的 地 方 子 类 就 能 
现 ， 再 结合 本 革 的 讲解 ， 我 们 可 以 得 出 这 样 一 个 通俗 的 规则 : ”接口 负 
责 定 义 public 属 性 和 方法 ， 并 且 声明 与 其 他 对 象 的 依赖 天 系 ， 抽 和 象 类 人 负 
责 公共 构造 部 分 的 实现 ， 实 现 类 准确 的 实现 业务 逻辑 ， 同 时 在 适当 的 
时 候 对 父 类 进行 细 化 。 


讲 了 这 么 多 ， 佑 计 大 家 对 “倒置 ”这 个 词 还 是 有 点 不 理解 ， 那 到 底 
什么 是 “倒置 ? 呢 ? 我 们 先 说 “ 正 置 ”是 什么 意 轧 ， 依 赖 正 置 整 是 类 间 的 
依赖 是 实 实在 在 的 实现 类 间 的 依赖 ， 也 就 古 面向 实现 编程 ， 这 也 是 正 
常人 的 思维 方式 ， 我 要 开 奔 驰 车 束 依 赖 奔驰 车 ， 我 要 使 用 笔记 本 电脑 


忠 直 接 依赖 笔记 本 电脑 ， 而 编写 程序 需要 的 是 对 现实 世界 的 事物 进行 
抽象 ， 抽 和 象 的 结 采 束 和 证 有 了 抽象 类 和 接口 ， 然 后 我 们 根据 系统 设计 的 
需要 产生 了 抽象 间 的 依赖 ， 代 替 了 人 们 传统 思维 中 的 事物 间 的 依 
赖 ，“ 倒 置 * 就 是 从 这 里 产生 的 。 


依赖 倒置 原则 的 优点 在 小 型 项 目 中 很 难 体现 出 来 ， 例 如 小 于 10 个 
人 月 的 项 目 ， 使 用 们 单 的 SSH 架 构 ， 基 本 上 不 费 太 大 力气 整 可 以 完 
成 ， 是 否 采用 依赖 倒置 原则 影响 不 大 。 但 是 ， 在 一 个 大 中 型 项 目 中 
采用 依赖 倒置 原则 有 非常 多 的 优点 ， 符 别 是 规避 一 些 非 技术 因素 引起 
的 问题 。 项 目 越 大 ， 需 求 变 化 的 概率 也 越 大 ， 通 过 采用 依赖 倒置 原则 
设计 的 接口 或 抽象 类 对 实现 类 进行 约束 ， 可 以 减少 需求 变化 引起 的 工 
作 量 剧 增 的 情况 。 人 员 的 变动 在 大 中 型 项 目 中 也 是 时 党 存在 的 ， 如 采 
设计 优 民 、 代 码 结构 清晰 ， 人 员 变 化 对 项 目的 影响 基本 为 零 。 大 中 型 
项 目的 维护 周期 一 般 都 很 长 ， 采 用 依赖 倒置 原则 可 以 让 维护 人 员 轻 松 
地 扩展 和 维护 。 


依赖 倒置 原则 是 6 个 设计 原则 中 最 难以 实现 的 原则 ， 它 是 实现 开 闭 
原则 的 重要 途径 ， 依 赖 倒置 原则 没有 实现 ， 束 别 想 实 现 对 扩展 开放 ， 
对 修改 关闭 。 在 项 目 中 ， 大 家 只 要 记 住 是 “ 面 同 接口 编程 ”就 基本 上 抓 
住 了 依赖 倒置 原则 的 核心 。 


讲 了 这 么 多 依赖 倒置 原则 的 优点 ， 我 们 也 来 打击 一 下 大 家 ， 在 现 
实 世界 中 确实 存在 着 必须 依赖 细 万 的 事物 ， 比 如 法 律 ， 吏 必须 依赖 细 


节 的 定义 。“ 杀 人 偿命 "在 中 国 的 法 律 中 古今 有 之 中 ， 那 这 里 的 “ 杀 

人 ”了 吏 是 一 个 抽象 的 含义 ， 怎 么 杀 ， 杀 什么 人 ， 为 什么 杀人 ， 都 没有 定 
义 ， 只 要 是 杀人 吏 统 统 得 偿命 ， 这 藉 是 有 问题 了 ， 好 人 杀 了 坏人 人， 还 
要 陪 上 目 己 的 一 条 性 命 ， 这 是 不 公正 的 ， 从 这 一 点 看 ， 我 们 在 实际 的 
项 目 中 使 用 依赖 倒置 原则 时 需要 审时度势 ， 不 要 抓 住 一 个 原则 不 放 ， 
每 一 个 原则 的 优点 都 是 有 限度 的 ， 并 不 是 放 之 四 海 而 缘 准 的 真理 ， 所 
以 别 为 了 遵循 一 个 原则 而 放弃 了 一 个 项 目的 终极 目标 : 投产 上 线 和 盘 
利 。 作 为 一 个 项 目 经 理 或 染 构 师 ， 应 该 懂得 技术 只 是 实现 目的 的 工 
具 ， 邯 恼 了 顶 涉 上 司 ， 设 计 做 得 再 河 有 党 ,代码 写 得 再 完美 ， 项 目 做 得 
再 符合 标准 ， 一 旦 项 目 亏 本 ， 产 品 投 入 大 于 产 出 ， 那 整体 就 是 扯淡 ! 
你 目 己 也 别 想 混 得 更 好 ! 


[1] 当年 汉 高 祖 刘 邦 入 关 后 与 老百姓 约法 三 草 ， 其 中 有 一 条 就 是 :“ 杀 
人 者 死 ， 念 人 及 盗 抵 罪 。” 


第 4 章 ”接口 隔离 原则 


4.1 接口 隔离 原则 的 定义 


在 讲 接口 隔离 原则 之 前 ， 爷 明确 一 下 我 们 的 主角 一 一 接口 。 接 口 
分 为 两 种 : 


e 实例 接口 (Object Interface) ， 在 Java 中 声明 一 个 类 ， 然 后 用 
new 关 键 字 产 生 一 个 实例 ， 它 是 对 一 个 类 型 的 事物 的 描述 ， 这 十 一 种 
接口 。 比 如 你 定义 Person 这 个 类 ， 人 然后 使 用 Person zhangSan=new 
Person(0) 产 生 了 一 个 实例 ， 这 个 实例 要 遵从 的 标准 殴 是 Person 这 个 类 ， 
Person 类 就 是 zhangSan 的 接口 。 疑 惑 ? 看 不 懂 ? 不 要 紧 ， 那 是 因为 让 
Java 语 言 浸 染 的 时 间 太 长 了 ， 只 要 知道 从 这 个 角度 来 看 ，Java 中 的 类 
也 是 一 种 接口 。 


e 类 接口 (Class Interface) ，Java 中 经 常 使 用 的 interface 关 键 字 定 
义 的 接口 。 


主角 已 经 定义 清楚 了 ， 那 什么 是 隔离 呢 ? 它 有 两 种 定义 ， 如 下 所 


e Clients should not be forced to depend upon interfaces that they 


don't use. (客户 端 不 应 该 依赖 它 不 需要 的 接口 。) 


e@ The dependency of one class to another one Should depend on the 
smallest possible interface. (类 间 的 依赖 关系 应 该 建立 在 最 小 的 接口 
et 


新 事物 的 定义 一 般 都 比较 难 理解 ， 睡 深 难 懂 是 正常 的 。 我 们 把 这 
两 个 定义 剖析 一 下 ， 移 说 第 一 种 定义 : “客户 端 不 应 该 依赖 它 不 需要 的 
接口 >， 那 依 赖 什么 ? 依赖 它 需 要 的 接口 ， 客 户 端 需要 什么 接口 承担 供 
什么 接口 ， 把 不 需要 的 接口 剔除 挥 ， 那 束 需 要 对 接口 进行 细 化 ， 保 证 
其 纯洁 性 ， 再 看 第 二 种 定义 : “类 间 的 依赖 天 系 应 该 建立 在 最 小 的 接口 
上 ”， 它 要 求 是 最 小 的 接口 ， 也 是 要 求 接口 细 化 ， 接 口 纯洁 ， 与 第 一 个 
定义 如 出 一 生 ， 只 十 一 个 事物 的 两 种 不 同 描述 。 


我 们 可 以 把 这 两 个 定义 概括 为 一 句 话 : 建立 单一 接口 ， 不 要 建立 
腓 肿 庞 大 的 接口 。 再 通俗 一 点 讲 : 接口 尽量 细 化 ， 同 时 接口 中 的 方法 
尽量 少 。 看 到 这 里 大 家 有 可 能 要 疑惑 了 ， 这 与 单一 职责 原则 不 是 相同 
的 吗 ? 错 ， 接 口 隔离 原则 与 单一 职责 的 审视 角度 是 不 相同 的 ， 单 一 职 
责 有 要求 的 是 类 和 接口 职责 单一 ， 注 重 的 是 职责 ， 这 是 业务 逻辑 上 的 划 
分 ， 而 接口 隔离 原则 要 求 接口 的 方法 尽量 少 。 例 如 一 个 接口 的 职责 6 
能 包含 10 个 方法 ， 这 10 个 方法 都 放 在 一 个 接口 中 ， 并 且 提 供给 多 个 模 
块 访问 ， 各 个 模块 按照 规定 的 权限 来 访问 ， 在 系统 外 通过 文档 约束 “不 


使 用 的 方法 不 要 访问 ”， 按 照 单一 职责 原则 是 允许 的 ， 按 照 接口 隔离 原 
则 是 不 允许 的 ， 因 为 它 要 求 “ 尽 量 使 用 多 个 专门 的 接口 *。 专门 的 接口 

指 什么 ? 束 古 指 提 供给 每 个 模块 的 者 应 该 是 单一 接口 ， 提 供给 几 个 模 

块 束 应 该 有 几 个 接口 ， 而 不 是 建立 一 个 庞大 的 腾 肿 的 接口 ， 容 纳 所 有 

的 客户 剖 访 问 。 


4.2 美女 何其 多 ， 观 点 各 不 同 


我 们 举例 来 说 明 接 口 隔离 原则 到 瓜 对 我 们 提出 了 什么 要 求 。 现 在 
男生 对 小 寻 女 的 称呼 ,使 用 频率 最 高 的 应 该 是 “美女 "了 吧 ， 你 在 大 街 
上 叫 一 声 :“， 美 女 ! ” 售 计 10 个 有 8 个 回头 ， 其 中 包括 那 位 著名 的 如 
化 。 美 文 的 标准 各 不 相同 ， 首 移 束 需要 定义 一 下 什么 是 美女 : 首 移 要 
面 够 好 看 ， 其 次 是 身材 要 纺 穹 ， 然 后 要 有 气质 ， 当 然 了 ， 这 三 者 各 人 
的 排列 顺序 不 一 样 ， 总 之 要 成 为 一 名 天女 承 必须 具备 : 面 狐 、 喘 材 和 
气质 ， 我 们 用 类 图 体现 一 下 星 探 (当然 ， 你 也 可 以 把 自己 想象 成 星 
探 ) 找 美女 的 过 程 ， 如 图 4-1 所 示 。 


AbstractSearcher <<imterface>> 
IPettyGirl 


+AbstractSearcher(IPettyGirl _pettyGirl) 
tHapbstract void show!() 


+vold goodLooking() 
+void niceFigure() 
+vold ereatTemperament() 


= EC 二 = 下 
| | | | 


图 4-1 星 探 寻找 美女 的 类 图 


定义 了 一 个 IPettyGil 接 口 ， 声 明 所 有 的 美文 都 应 该 有 
goodLooking、mniceFigure 和 great-Temperament， 然 后 又 定义 了 一 个 抽象 


类 AbstractSearcher， 其 作用 职 是 搜索 美女 并 显示 其 信息 ， 只 要 美女 都 
按照 这 个 规范 定义 ，Searcher ( 星 探 ) 就 轻松 多 了 ， 美 女 类 的 实现 如 代 
码 清 单 4-1 所 示 。 


代码 清单 4-1 美女 类 


public interface IPettyGirl { 
// 要 有 妈 好 的 面孔 
public void goodLooking(); 
// 要 有 好 身材 


public void niceFigure(); 
// 要 有 气质 


public void greatTemperament ( ) ; 


美女 的 标准 定义 完毕 ， 具 体 的 美女 实现 类 如 代码 清单 4-2 所 示 。 


代码 清单 4-2 美女 实现 类 


public class PettyGirl implements IPettyGirl { 
private String name; 
// 美 女 都 有 名 字 
public PettyGirl(String _name)t{ 
this.name=_name; 


// 脸 蛋 漂 亮 

public void goodLooking() { 
System.out.println(this.name + "--- 脸 蛋 很 漂亮 !1")，; 

} 

// 气 质 要 好 

public void greatTemperament() { 
System.out.println(this.name +"--- 气 质 非 常 好 !")， 

} 

// 身 材 要 好 

public void niceFigure() { 
System.out,println(this,name + "--- 上 身材 非常 棱 !")， 


通过 三 个 方法 ， 把 对 类 文 的 要 求 都 定义 出 来 了 ， 按 照 这 个 标准 ， 
如 花 好 娟 被 排除 在 美女 标准 之 外 了 。 有 美女 ， 束 有 搜索 美女 的 星 探 ， 
其 具体 实现 如 代码 清单 4-3 所 示 。 


代码 清单 4-3 星 探 抽象 类 源 代码 


public abstract class AbstractSearcher { 
protected IPettyGirl pettyGirl; 
public AbstractSearcher(IPettyGirl _pettyGirl){ 
this.pettyGirl = _pettyGirl; 


， 
// 搜 索 美 女 ， 列 出 美女 信息 


public abstract void show( ); 


星 探 的 实现 类 就 比较 简单 了 ， 其 源 代码 如 代码 清单 4.4 所 示 。 


代码 清单 4-4 星 探 类 


public class Searcher extends AbstractSearchert{ 
public Searcher(IPettyGirl _pettyGirl1)t{ 
super(_pettyGirl); 


3 
// 展 示 美 女 的 信息 
public void show(){ 
System.out.println("-------- 美女 的 信息 如 下 : --------- 


// 展 示 面 容 

super .pettyGirl.goodLooking( ); 
// 展 示 身 材 

super .pettyGirl.niceFigure(); 
// 展 示 气 质 

super .pettyGirl.greatTemperament(); 


场景 中 的 两 个 角色 美女 和 星 探 都 已 经 出 现 了 ， 需 要 写 一 个 场景 类 
来 串联 起 各 个 角色 ， 场 景 类 的 实现 如 代码 清单 4-5 所 示 。 


代码 清单 4-5 场景 类 


public class Client { 
// 搜 索 并 展示 美女 信息 
public static void main(String[|] args) { 
// 定 义 一 个 美女 
IPettyGirl yanYan = new PettyGirl(" 奸 嫣 ")， 
AbstractSearcher searcher = new Searcher(yanYan); 
searcher .show( ) ; 


星 探 搜索 美女 的 运行 结果 如 下 所 示 : 


ee 美 次 的 信息 各 下 os 


嫣 婚 --- 脸 蛋 很 漂亮 ! 


嫂 媚 --- 喘 材 非常 棒 ! 


媚 媚 --- 气 质 非常 好 ! 


星 探 寻找 美女 的 程序 开发 完毕 了 ， 运 行 结 末 也 正确 。 我 们 回头 来 
想 想 这 个 程序 有 没有 问题 ， 思 考 一 下 IPettyGirl 这 个 接口 ， 这 个 接口 是 
人 否 做 到 了 最 优化 设计 ? 答案 是 没有 ， 还 可 以 对 接口 进行 优化 。 


我 们 的 审美 观点 都 在 改变 ， 美 女 的 定义 也 在 变化 。 唐 朝 的 杨 贵妃 
如 果 活 在 现在 这 个 年 代 非 做 愧 而 死 不 可 ， 为 什么 ? 胖 呀 ! 但 是 胖 并 不 
影响 她 入 选中 国 四 大 美女 ， 说 明 当 时 的 审美 观 与 现在 是 有 差异 的 。 当 


然 ， 随 着 时 代 的 发 展 我 们 的 审美 观 也 在 变化 ， 当 你 发 现 有 一 个 女孩 ， 
脸蛋 不 怎么 样 ， 身 材 也 一 般 般 ， 但 是 气质 非常 好 ， 我 相信 大 部 分 人 都 
会 把 这 样 的 女孩 叫 美 女 ， 审 美 素质 提升 了 ， 束 产生 了 气质 型 美女 ,但 
是 我 们 的 接口 却 定义 了 美女 必须 是 三 者 都 具备 ， 按 照 这 个 标准 ， 气 质 
型 美女 就 不 能 算 美女 ， 那 怎么 办 ? 可 能 你 要 说 了 ， 我 重新 扩展 一 个 美 
女 类 ， 只 实现 greatTemperament 方 法 ， 其 他 两 个 方法 置 空 ， 什 么 都 不 
写 ， 不 就 可 以 了 吗 ? 聪明 ,但 是 行 不 通 ! 为 什么 呢 ? 星 探 
AbstractSearcher 依 赖 的 是 IPettyGirl 接 口 ， 它 有 三 个 方法 ， 你 只 实现 了 
两 个 方法 ， 星 探 的 方法 是 不 是 要 修改 ? 我 们 上 面 的 程序 打印 出 来 的 信 
息 少 了 两 条 ， 还 让 星 探 怎么 去 辨别 是 不 是 美女 呢 ? 


分 析 到 这 里 ， 我 们 发 现 接 口 IPettyGi 的 设计 是 有 缺陷 的 ， 过 于 庞 
大 了 ， 容 纳 了 一 些 可 变 的 因素 ， 根 据 接 口 隔离 原则 ， 星 控 
AbstractSearcher 应 该 依赖 于 具有 部 分 特质 的 女孩 子 ， 而 我 们 却 把 这 坚 
特质 都 封闭 了 起 来 ， 放 到 了 一 个 接口 中 ， 封闭 过 度 了 ! 问题 找到 了 ， 
我 们 重新 设计 一 下 类 图 ， 修 改 后 的 类 图 如 图 4-2 所 示 。 


把 原 IPettyGifl 接 口 拆 分 为 两 个 接口 ， 一 种 是 外 形 美的 美女 
IGoodBodyGirl， 这 类 美女 的 特点 束 是 脸蛋 和 壬 材 极 梭 ， 超 一 流 ， 但 是 
没有 审美 素质 ， 比 如 随地 吐 痰 ， 文 化 程度 比较 低 ， 另外 一 种 是 气质 美 
的 美女 IGreatTemperamentGil ， 谈 叶 和 修养 都 非常 高 。 我 们 把 一 个 比 
较 腾 肿 的 接口 拆 分 成 了 两 个 专门 的 接口 ， 灵 活性 提高 了 ， 可 维护 性 也 


增加 了 ， 不 管 以 后 是 要 外 形 美的 美女 还 是 气质 美的 美女 都 可 以 轻松 地 
通过 PettyGinl 定 义 。 两 种 类 型 的 美女 定义 如 代码 清单 4.6 所 示 。 


AbstractSearcher 


Searcher 


tAbstractSearcher(IGreatTemperamentGirl gretTemperamentGirl) 
tHAbstractSearcher(IGoodBodyG1r] _goodBodyGir]) 


tabstract void show() 


<<Interface>> <<interface>> 
IGreatTemperamentGirl IGoodBodyGirl 


tvoid greatTemperament() +vold goodLookme() 
+Vold niceFigure() 


[petecn | 
| | 
| | 


图 4-2 修改 后 的 星 探 寻找 美女 类 图 


代码 清单 4-6 两 种 类 型 的 美女 定义 


public interface IGoodBodyGirl { 
// 要 有 嫌 好 的 面孔 
public void goodLooking(); 
// 要 有 好 身材 


public void niceFigure( ); 


public interface IGreatTemperamentGirl { 
// 要 有 气质 


public void greatTemperament ( ) ; 


按照 脸蛋 、 身 材 、 气 质 都 具备 才 算 美女 ， 实 现 类 实现 两 个 接口 ， 
如 代码 清单 4-7 所 示 。 


代码 清单 4-7 最 标准 的 美女 


public class PettyGirl implements 
IGoodBodyGirl,IGreatTemperamentGirl { 
private String name; 
// 美 女 都 有 名 字 
public PettyGirl(String _name)t{ 
this.name=_name; 


// 脸 蛋 漂亮 
public void goodLooking() { 
System.out.println(this.name + "--- 脸 蛋 很 漂亮 1"); 


} 

// 气 质 要 好 

public void greatTemperament() { 
System.out.println(this.name +"--- 气 质 非 常 好 !")，; 


} 

// 身 材 要 好 

public void niceFigure() { 
System.out.println(this.name + "--- 身 材 非常 棱 !"); 


重 过 这 样 的 重 构 以 后 ， 不 管 以 后 是 要 气质 美女 还 是 要 外 形 美 女 ， 
都 可 以 保持 接口 的 稳定 。 当 然 ， 你 可 能 要 说 了 ， 以 后 可 能 审美 观点 再 
发 生 改 变 ， 只 有 脸蛋 好 看 就 是 美女 ， 那 这 个 IGoodBody 接 口 还 是 要 修 
改 的 呀 ， 确 实 是 ， 但 是 设计 是 有 限度 的 ， 不 能 无 限 地 考虑 未 来 的 变更 
情况 ， 否 则 天 会 陷入 设计 的 泥潭 中 而 不 能 自拔 。 


以 上 把 一 个 肥 肿 的 接口 变更 为 两 个 独立 的 接口 所 依赖 的 原则 就 是 
接口 隔离 原则 ， 让 星 探 AbstractSearcher 依 赖 两 个 专用 的 接口 比 依 赖 一 
个 综合 的 接口 要 灵活 。 接 口 是 我 们 设计 时 对 外 提供 的 契约 ， 通 过 分 散 


定义 多 个 接口 ， 可 以 预防 未 来 变更 的 扩散 ， 近 高 系统 的 灵活 性 和 可 维 
人 


4.3 剑 证 接口 的 纯洁 性 


接口 隔离 原则 是 对 接口 进行 规范 约束 ， 其 包含 以 下 4 层 合 义 : 
e 接口 要 尽量 小 


这 是 接口 隅 离 原则 的 核心 定义 ， 不 出 现 腾 肿 的 接口 (Fat 
Interface) ,但 是 “小 ”是 有 限度 的 ， 首 先 就 是 不 能 违反 单一 职责 原则 ， 
什么 意思 呢 ? 我 们 在 单一 职责 原则 中 提 到 一 个 IPhone 的 例子 ， 在 这 里 ， 
我 们 使 用 单一 职责 原则 把 两 个 职责 分 解 到 两 个 接口 中 ， 类 图 如 图 4-3 所 


修 ° 


<<interface>> <<mterface>> 
IConnectionManager IDataTransfer 


En 
+void dial(String phone Number) >" +DataTransfer(IConnectionManager cm) 
tvoid huangup() +void chat(Object o) 

tvoid answer(Object 0) 


ConnectionManager 


图 4-3 电话 类 图 


仔细 分 析 一 下 IConnectionManager 接 口 是 否 还 可 以 再 继续 拆 分 下 
去 ， 挂 电话 有 两 种 方式 : 一 种 是 正常 的 电话 挂 断 ， 一 种 是 电话 异常 挂 
机 ， 比 如 突然 没 电 了 ， 通 信 当 然 就 断 了 。 这 两 种 方式 的 处 理应 该 是 不 
同 的 ， 为 什么 呢 ? 正常 挂 电话 ， 对 方 接受 到 挂机 信号 ， 计 费 系 统 也 就 
停止 计 费 了 ， 那 手机 没 电 了 这 种 方式 就 不 同 了 ， 它 是 信号 丢失 了 ， 中 
继 服务 器 检查 到 了 ， 然 后 通知 计 改 系统 停止 计 费 ， 否 则 你 的 费用 不 是 
要 闫 狂 地 增长 了 吗 ? 


思考 到 这 里 ， 我 们 是 不 是 束 要 动手 把 IConnectionManager 接 口 拆 夫 
成 两 个 ， 一 个 接口 是 负责 连接 ， 一 个 接口 是 负责 挂 电话 ? 是 要 这 样 做 
吗 ? 且慢 ， 让 我 们 再 思考 一 下 ， 如 末 拆 分 了 ， 那 束 不 符合 单一 职 贡 原 
则 了 ， 因 为 从 业务 逻辑 上 来 讲 ， 通 信 的 建立 和 关闭 已 经 是 最 小 的 业务 
单位 了 ， 再 细 分 下 去 就 是 对 业务 或 是 协议 (其 他 业务 逻辑 ) 的 拆 分 
了 。 想 想 看 ， 一 个 电话 要 关心 3G 协 议 ， 要 考虑 中 继 服务 釉 ， 等 等 ， 这 
个 电话 还 怎么 设计 得 出 来 呢 ? 从 业务 层次 来 看 ， 这 样 的 设计 就 是 一 个 
失败 的 设计 。 一 个 原则 要 拆 ， 一 个 原则 又 不 要 拆 ， 那 该 上 怎么 办 ? 好 
办 ， 根 据 接口 隔离 原则 拆 分 接口 时 ， 首 先 必须 满足 单一 职责 原则 。 


e 接口 要 高 内 聚 


什么 是 高 内 聚 ? 高 内 聚 就 是 提高 接口 类、 模块 的 处 理 能 力 ， 减 
少 对 外 的 交互 。 比 如 你 告诉 下 属 “ 到 奥巴马 的 办 公 室 偷 一 个 xxx 文 件 ”， 
然后 听 到 下 属 用 坚定 的 口吻 回答 你 :“ 是 ， 保 证 完成 任务 ! ”一 个 月 


， 你 的 下 属 还 真 的 把 xxx 文 件 放 到 你 的 办 公 梨 上 了 ， 这 种 不 讲 任 何 条 
、 立刻 完成 任务 的 行为 就 是 高 内 聚 的 表现 。 具 体 到 接口 隔离 原则 台 
是 ， 要 求 在 接口 中 尽量 少 公布 public 方 法 ， 接 口 是 对 外 的 承诺 ， 承 诺 越 
少 对 系统 的 开发 越 有 利 ， 变 更 的 风险 也 束 越 少 ， 同 时 也 有 利于 降低 成 
pe 


i 


这 


e 定制 服务 


一 个 系统 或 系统 内 的 模块 之 间 必 然 会 有 耦合 ， 有 耦合 就 要 有 相互 
访问 的 接口 “并 不 一 定 就 是 Java 中 定义 的 Interface， 也 可 能 是 一 个 类 或 
单纯 的 数据 交换 ) ， 我 们 设计 时 就 需要 为 各 个 访问 者 〈 即 客户 端 ) 定 
制服 务 ， 什 么 是 定制 服务 ?定制 服务 就 是 单独 为 一 个 个 体 提供 优良 的 
服务 。 我 们 在 做 系统 设计 时 也 需要 考虑 对 系统 之 间或 模块 之 间 的 接口 
采用 定制 服务 。 采 用 定制 服务 就 必然 有 一 个 要 求 : 只 提供 访问 者 需要 
的 方法 ， 这 是 什么 意思 ? 我 们 举 个 例子 来 说 明 ， 比 如 我 们 开发 了 一 个 
图 书 管理 系统 ， 其 中 有 一 个 查询 接口 ， 方 便 管 理 员 查 询 图 书 ， 其 类 图 
如 图 4-4 所 示 。 


<<mterface>> 
IBookSearcher 
| 
+void searchByAuthor() 


+void searchByTitle() 

+void searchByPublisher() 

+vold searchByCatagory() 
+void complexSearch(Map map) 


图 4-4 图 书 查 询 类 图 


在 接口 中 定义 了 多 个 查询 方法 ， 分 别 可 以 按照 作者 、 标 题 、 出 版 
社 、 分 类 进行 查询 ， 最 后 还 提供 了 混合 查询 方式 。 程 序 写 好 了 ， 投 产 
上 线 了 ， 突 然 有 一 天 发 现 系统 速度 非常 慢 ， 然 后 束 开 始 痛 藻 地 分 析 ， 
最 终 发 现 是 访问 接口 中 的 complexSearch(Map map) 方 法 并 发 量 太 大 ， 导 
致 应 用 服务 器 性 能 下 降 ， 然 后 继续 跟踪 下 去 发 现 这 些 查询 都 是 从 公 网 
上 发 起 的 ， 进 一 步 分 析 ， 找 到 问题 ， 提 供给 公 网 〈 公 网 项 目 是 另外 一 
个 项 目 组 开发 的 ， 的 查询 接口 和 提供 给 系统 内 管理 人 员 的 接口 是 相同 
的 ， 都 征 IBookSearcher 接 口 ， 但 是 权限 不 同 ， 系 统管 理 人 员 可 以 通过 
接口 的 complexSearch 方 法 查询 到 所 有 的 书籍 ， 而 公 网 的 这 个 方法 是 被 
限制 的 ， 不 返回 任何 值 ， 在 设计 时 通过 口头 约束 ， 这 个 方法 旦 不 可 被 
调用 的 ， 但 是 由 于 公 网 项 目 组 的 焉 急 ， 这 个 方法 还 是 公布 了 出 去 ， 虽 
然 不 能 返回 结 有 琳 ， 但 是 还 是 引起 了 应 用 服务 器 的 性 能 巨 慢 的 情况 发 
生 ， 这 就 是 一 个 腾 肿 接口 引起 性 能 故障 的 案例 。 


问题 找到 了 ， 残 需要 把 这 个 接口 进行 重 构 ， 将 IBookSearcher 拆 分 
为 两 个 接口 ， 分 别 为 两 个 模块 提供 定制 服务 ， 修 改 后 的 类 图 如 图 4-5 所 
示 o 


<<mterface>> <<Interface>> 
ISimple BookSearcher IComplexBookSearcher 


+vold searchByAuthor() +vold complexSearch(Map map 
+vold searchByTitle() 

+vold searchByPublisher() 

Hvoid searchByCatagory() 


图 4-5 修改 后 的 图 书 查 询 类 图 


提供 给 管理 人 员 的 实现 类 同时 实现 了 ISimpleBookSearcher 和 
IComplexBookSearcher 两 个 接口 ， 原 有 程序 不 用 做 任何 改变 ， 而 提供 给 
公 网 的 接口 变 为 ISimpleBookSearcher， 只 人 允许 进行 简单 的 查询 ， 单 独 为 
其 定制 服务 ,减少 可 能 引起 的 风险 。 


e 接口 设计 是 有 限度 的 


接口 的 设计 粒度 越 小 ， 系 统 越 灵活 ， 这 是 不 争 的 事实 。 但 是 ， 灵 
活 的 同时 也 带 来 了 结构 的 复杂 化 ， 开 发 难度 增加 ， 可 维护 性 降低 ， 这 
不 是 一 个 项 目 或 产品 所 期 望 看 到 的 ， 所 以 接口 设计 一 定 要 注意 适度 ， 
这 个 “ 度 ” 如 何 来 判断 呢 ? 根据 经 验 和 常识 判断 ， 没 有 一 个 固化 或 可 测 
量 的 标准 。 


4.4 最 住 实践 


接口 隔离 原则 是 对 接口 的 定义 ， 同 时 也 是 对 类 的 定义 ， 接 口 和 类 
尽量 使 用 原子 接口 或 原子 类 来 组 装 。 但 是 ， 这 个 原子 该 怎么 划分 是 设 
计 模 式 中 的 一 大 难题 ， 在 实践 中 可 以 根据 以 下 几 个 规则 来 衡量 : 


。 一 个 接口 只 服务 于 一 个 子 模块 或 业务 逻辑 ; 


e 通过 业务 逻辑 压缩 接口 中 的 public 方 法 ， 接 口 时 常 去 回顾 ， 尽 量 
让 接口 达到 “ 满 身 筋骨 肉 ”"， 而 不 是 “ 肥 嘟 嘟 * 的 一 大 堆 方 法 ; 


e 已 经 被 污染 了 的 接口 ， 尽 量 去 修改 ， 大 变更 的 风险 较 大 ， 则 采 
用 适 配 莫 模式 进行 转化 处 理 ; 


e。 了 解 环境 ， 拒 绝育 从 。 每 个 项 目 或 产品 都 有 特定 的 环境 因素 ， 
别 看 到 大 师 是 这 样 做 的 你 就 照抄 。 千 万 别 ， 环 境 不 同 ， 接 口 拆 分 的 标 
准 束 不 同 。 深 入 了 解 业务 逻辑 ， 最 好 的 接口 设计 束 出 目 你 的 手中 


接口 隔离 原则 和 其 他 设计 原则 一 样 ， 都 需要 花费 较 多 的 时 间 和 精 
力 来 进行 设计 和 筹划 ， 但 是 它 市 来 了 设计 的 灵活 性 ， 让 你 可 以 在 业务 
人 员 提 出 “无 理 ” 有 要求 时 轻松 应 付 。 贯 彻 使 用 接口 隔离 原则 最 好 的 方法 
束 古 一 个 接口 一 个 方法 ， 保 证 绝对 符合 接口 隔离 原则 (有 可 能 不 符合 
单一 职责 原则 ) ， 但 你 会 采用 吗 ? 不 会 ， 除 非 你 是 疯子 ! 那 怎么 才能 


正确 地 使 用 接口 隔离 原则 呢 ? 管 案 是 根据 经 验 和 第 识 决 定 接 口 的 粒度 
大 小 ， 接 口 粒 度 太 小 ， 导 致 接口 数据 剧 增 ， 开 发 人 员 哈 死 在 接口 的 海 
洋 里 ， 接 口 粒 度 太 大 ， 灵 活性 降低 ， 无 法 提供 定制 服务 ， 给 整体 项 目 
市 来 无 法 预料 的 风险 。 


皇 么 准确 地 实践 接口 隔离 原则 ? 实践 、 经 验 和 领情! 


第 5 章 ” 迪 米 特 法 则 


5.1 迪 米 竺 法则 的 定义 


迪 米 特 法 则 (Law of Demeter，LoD) 也 称 为 最 少 知识 原则 
(Least Knowledge Principle，LKP) ， 虽 然 名 字 不 同 ， 但 描述 的 是 同 
一 个 规则 : 一 个 对 象 应 该 对 其 他 对 象 有 最 少 的 了 解 。 通 俗 地 讲 ， 一 个 
类 应 该 对 目 己 需要 耦合 或 调用 的 类 知道 得 最 少 ， 你 〈 被 耦合 或 调用 的 
类 ) 的 内 部 是 如 何 复杂 都 和 我 没关系 ， 那 是 你 的 事情 ， 我 就 知道 你 提 
供 的 这 么 多 public 方 法 ， 我 就 调用 这 么 多 ， 其 他 的 我 一 概 不 天 心 。 


5.2 我 的 知识 你 知道 得 越 少 越 好 


迪 米 特 法 则 对 类 的 低 硝 合 所 出 了 明确 的 要 求 ， 其 包含 以 下 4 层 合 
义 。 


1. 只 和 朋友 交流 


迪 米 特 法 则 还 有 一 个 英文 解释 是 : Only talk to your immediate 
friends (只 与 直接 的 朋友 通信 。) 什么 叫做 直接 的 朋友 呢 ? 每 个 对 象 都 
必然 会 与 其 他 对 象 有 耦合 天 系 ， 两 个 对 象 之 间 的 硝 合 束 成 为 朋友 天 
系 ， 这 种 关系 的 类 型 有 很 多 ， 例 如 组 合 、 聚 合 、 依 赖 等 。 下 面 我 们 将 
举例 说 明 如 何 才能 做 到 只 与 直接 的 朋友 交流 。 


传说 中 有 这 样 一 个 故事 ， 老 师 想 让 体育 委员 确认 一 下 全 班 女 生来 
齐 没 有 ， 就 对 他 说 : “你 去 把 全 班 女 生 清 一 下 。” 体 育 委员 没 听 清 楚 ， 
就 问 道 : “ 呀 ，.……. 那 亲 哪个 ? ”老师 无 语 了 ， 我 们 来 看 这 个 笑话 怎么 
用 程序 来 实现 ， 类 图 如 图 5-1 所 示 。 


rs 


Hvold commond(GroupLeader groupLeader) 


Teacher 类 的 commond 方 法 负责 发 送 命令 给 体育 委员 ， 命 令 他 清点 
女生 ， 其 实现 过 程 如 代码 清单 5-1 所 示 。 


代码 清单 5-1 老师 类 


public class Teacher { 
// 老 师 对 学 生发 布 命令 ， 清 一 下 女生 
public void dt groupLeader ){ 
List listGirls = new ArrayList(); 
// 初 始 化 女生 
for(int i=0;i<20;i++){ 
listGirls.add(new Girl()); 


} 
// 告 诉 体育 委员 开始 执行 清查 任务 


groupLeader .countGirls(1istGirls); 


证 


老师 只 有 一 个 方法 commond， 先 定义 出 所 有 的 文生 ， 然 后 发 布 命 
令 给 体育 委员 ， 去 清点 一 下 女生 的 数量 。 体 育 委 员 GroupLeader 的 实现 
过 程 如 代码 清单 5-2 所 示 。 


代码 清单 5-2 体育 委员 类 实现 过 程 


public class GroupLeader { 
// 清 查 女 生 数 量 
public void countGirls(List<Girl> listGirls)t{ 
System.out.println(" 女 生 数 量 是 : "+1listGirls.size()); 


老师 类 和 体育 委员 类 都 对 女生 类 产生 依赖 ， 而 且 女 生 类 不 需要 执 
行 任何 动作 ， 因 此 定义 一 个 空 类 ， 其 实现 过 程 如 代码 清单 5-3 所 示 。 


代码 清单 5-3 女生 类 


public class Girl { 
} 


故事 中 的 三 个 角色 都 已 经 有 了 ， 表 定义 一 个 场景 类 来 搬 述 这 个 故 
事 ， 其 实现 过 程 如 代码 清单 5-4 所 示 。 


代码 清单 5-4 场景 


public class Client { 
public static void main(String[] args) { 
Teacher teacher= new Teacher(); 
// 老 师 发 布 命令 


teacher .commond(new GroupLeader() ) ; 


ww 


运行 结果 如 下 所 示 : 


女生 数量 是 : 20 


体育 委员 按照 老师 的 要 求 对 女生 进行 了 清点 ， 并 得 出 了 数量 。 我 
们 回 过 头 来 思考 一 下 这 个 程序 有 什么 问题 ， 首 先 确 定 Teacher 类 有 几 个 
朋友 类 ， 它 仅 有 一 个 朋友 类 一 -GroupLeader。 为 什么 G 训 不 是 朋友 类 
呢 ? Teacher 也 对 它 产生 了 依赖 关系 呀 ! 朋友 类 的 定义 是 这 样 的 ;出 现 
在 成 员 变 量 、 方 法 的 输入 输出 参数 中 的 类 称 为 成 员 朋 友 类 ， 而 出 现在 
方法 体内 部 的 类 不 属于 朋友 类 ， 而 Girnl 这 个 类 就 是 出 现在 commond 方 法 
体内 ， 因 此 不 属于 Teacher 类 的 朋友 类 。 巡 米 特 法 则 告诉 我 们 一 个 类 只 
和 朋友 类 交流 ， 但 是 我 们 刚刚 定义 的 commond 方 法 却 与 Gitl 类 有 了 交 
流 ， 声 明了 一 个 List<Girls> 动 态 数组 ， 也 就 是 与 一 个 陌生 的 类 Gin 有 了 
交流 ， 这 样 就 破坏 了 Teacher 的 健壮 性 。 方 法 是 类 的 一 个 行为 ， 类 竟然 
不 知道 自己 的 行为 与 其 他 类 产生 依赖 关系 ， 这 是 不 允许 的 ， 严 重 违反 
了 迪 米 特 法 则 。 


问题 已 经 发 现 ， 我 们 修改 一 下 程序 ， 将 类 图 稍 作 修改 ， 如 图 5-2 所 


一 一 一 一 一 一 一 一 一 一 一 一 


+void commond(GroupLeader groupLeader) 


+GroupLeader(List<Grl> tstGtrls) 
+void countGirls( ) 


图 5-2 修改 后 的 类 图 


在 类 图 中 去 掉 Teacher 对 Gitl 类 的 依赖 关系 ， 修 改 后 的 Teacher 类 如 
代码 清单 5-5 所 示 。 


代码 清单 5-5 修改 后 的 老师 类 


public class Teacher { 
// 老 师 对 学 生发 布 命令 ， 清 一 下 女生 
public void commond(GroupLeader groupLeader ){ 
// 告 诉 体育 委员 开始 执行 清 碍 任务 
groupLeader .countGirls(); 


修改 后 的 GroupLeader 类 如 代码 清 代 5-6 所 示 。 


代码 清单 5-6 修改 后 的 体育 委员 类 


public class GroupLeader { 
private List<Girl> listGirls,; 
// 传 递 全 班 的 女生 进来 
public GroupLeader (List<Girl> _listGirls)t{ 


this.1istGirls = listGirls; 


} 
// 清 查 女 生 数 量 
public void countGirls(){ 
System.out.println(" 女 生 数 量 
是 : "+this.listGirls.size()); 


} 


在 GroupLeader 类 中 定义 了 一 个 构造 函数 ， 通 过 构造 钞 数 传递 了 依 
赖 天 系 。 同 时 ， 对 场景 类 也 进行 了 一 些 修改 ， 如 代码 清单 5-7 所 示 。 


代码 清单 5-7 修改 后 的 场景 


public class Client { 

public static void main(String[] args) { 
// 产 生 一 个 女生 群体 
List<Girl> listGirls = new ArrayList<Gir]l>(); 
// 初 始 化 女生 
for(int i=0;i<20;i++){ 

listGirls.add(new Girl()); 

} 


Teacher teacher= new Teacher(); 
// 老 师 发 布 命令 


teacher ,commond (new GroupLeader (listGir]ls)); 


对 程序 进行 了 简单 的 修改 ， 把 Teacher 中 对 List<Girl> 的 初始 化 移动 
到 了 场景 类 中 ， 同 时 在 GroupLeader 中 增加 了 对 Girl 的 注入 ， 避 开 了 
Teacher 类 对 陌生 类 Gin 的 访问 ， 降 低 了 系统 间 的 耦合 ， 提 高 了 系统 的 健 
壮 性 。 


注意 ”一 个 类 只 和 朋友 交流 ， 不 与 陌生 类 交流 ， 不 要 出 现 
getA0.getB0.getC0.getDO 这 种 情况 〈 在 一 种 极端 的 情况 下 允许 出 现 这 


种 访问 ， 即 每 一 个 点 号 后 面 的 返回 类 型 都 相同 ) ， 类 与 类 之 间 的 关系 
征 建立 在 类 间 的 ， 而 不 是 方法 间 ， 因 此 一 个 方法 尽量 不 引入 一 个 类 中 
不 存在 的 对 象 ， 当 然 ，JDK API 提 供 的 类 除外 。 


2. 朋友 间 也 是 有 距离 的 


人 和 人 之 间 是 有 距离 的 ， 太 远 关 系 逐 渐 瑰 远 ， 最 终 形 同 隔 路 ， 太 
近 就 相互 刺 伤 。 对 朋友 关系 描述 最 贴切 的 故事 就 是 : 两 只 刺 猜 取暖 ， 
太 远 取 不 到 暖 ， 太 近 刺 伤 了 对 方 ， 必 须 保 持 一 个 既 能 取暖 又 不 刺 伤 对 
方 的 距离 。 迪 米 特 法 则 束 写 对 这 个 距离 进行 描述 ， 即 使 是 朋友 类 之 间 
也 不 能 无 话 不 说 ， 无 所 不 知 。 


我 们 在 安装 软件 的 时 候 ， 经 常会 有 一 个 导 癌 动作 ， 第 一 步 是 确认 
征 否 安装 ， 第 二 步 确 认 License， 再 然后 选择 安装 目录 ..……… 这 是 一 个 典 
型 的 顺序 执行 动作 ， 具 体 到 程序 中 就 是 : 调用 一 个 或 多 个 类 ， 先 执行 
第 一 个 方法 ， 然 后 是 第 二 个 方法 ， 根 据 返 回 结 琳 再 来 看 是 否 可 以 调用 
第 三 个 方法 ， 或 痢 第 四 个 方法 ， 等 等 ， 其 类 图 如 图 5-3 所 示 。 


InstallSoftware 
| 


| 
+void mstallWizard( Wizard wizard) +int first() 
+nt second() 


+int third() 


图 5-3 软件 安装 过 程 类 图 


很 测 单 的 类 图 ， 实 现 软件 安装 的 过 程 ， 其 中 firrst 方 法 定义 第 一 步 做 
什么 ，second 方 法 定义 第 二 步 做 什么 ，third 方 法 定义 第 三 步 做 什么 ， 其 
实现 过 程 如 代码 清单 5-8 所 示 。 


代码 清单 5-8 导向 类 


public class Wizard { 
private Random rand = new 
Random(System.currentTimeMil]lis( )); 
// 第 一 步 
public int first(){ 
System.out .printlin(" 执 行 第 一 个 方法 ,.,")， 
return rand.nextInt(100); 


} 

// 第 二 步 

public int second(){ 
System.out.printlin(" 执 行 第 二 个 方法 ,.,")，; 
return rand.nextInt(100); 


} 

// 第 三 个 方法 

public int third(){ 
System.out.println(" 执 行 第 三 个 方法 ...")， 
return rand.nextInt(100); 


在 Wizard 类 中 分 别 定义 了 三 个 步骤 方法 ， 每 个 步骤 中 都 有 相关 的 
业务 逻辑 完成 指定 的 任务 ， 我 们 使 用 一 个 随机 函数 来 代 蔡 业务 执行 的 
返回 值 。 软 件 安装 InstallSoftware 类 如 代码 清单 5-9 所 示 。 


代码 清单 5-9 InstallSoftware 类 


public class InstallSoftware { 
public void installwizard(Wizard wizard)t{ 


int first = wizard.first(); 
// 根 据 first 返 回 的 结果 ， 看 是 否 需 要 执行 second 


If(first>50){ 

int second = wizard.second(); 

if(second>50)t 
int third = wizard.third(); 
if(third >50)f{ 

wizard.first(); 
} 
} 
} 


根据 每 个 方法 执行 的 结果 决定 是 否 继续 执行 下 一 个 方法 ， 模 拟人 
工 的 选择 操作 。 场 景 类 如 代码 清单 5-10 所 示 。 


代码 请 单 5-10 场景 


public class Client { 
public static void main(String[] args) { 
InstallSoftware invoker = new InstallSoftware(); 
invoker.installwizard(new Wizard( )); 


以 上 程序 很 简单 ， 运 行 结果 和 随机 数 有 关 ， 每 次 的 执行 结果 都 不 
相同 ， 需 要 读者 自己 运行 并 查看 结果 。 程 序 虽然 简单 ， 但 是 隐藏 的 问 
题 可 不 简单 ， 思 考 一 下 程序 有 什么 问题 。Wizard 类 把 太 多 的 方法 暴露 
给 InstallSoftware 类 ， 两 者 的 朋友 关系 太 订 密 了 ， 耦 合 关系 变 得 异常 牢 
。 如果 要 将 Wizard 类 中 的 first 方 法 返回 值 的 类 型 由 int 改 为 boolean， 就 
需要 修改 InstallSoftware 类 ， 从 而 把 修改 变更 的 风险 扩散 开 了 。 因 此 ， 
这 样 的 耦合 是 极度 不 合适 的 ， 我 们 需要 对 设计 进行 重 构 ， 重 构 后 的 类 
图 如 图 5-4 所 示 。 


InstallSoftyware 


+void installWizard( Wizard wizard) -Int first() 


-int second() 
-int third() 
+void mstallWizard() 


图 5-4 重 构 后 的 软件 安装 过 程 类 图 


在 Wizard 类 中 增加 一 个 installWizard 方 法 ， 对 安装 过 程 进 行 封 装 ， 
同时 把 原 有 的 三 个 public 方 法 修改 为 private 方 法 ， 如 代码 清单 5-11 所 


修 ° 


代码 清单 5-11 修改 后 的 导 癌 类 实现 过 程 


public class Wizard { 
private Random rand = new 
Random(System.currentTimeMil]lis()); 
// 第 一 步 
private int first()t{ 
System.out.println( "执行 第 一 个 方法 ..."); 
return rand.nextInt(100); 


} 

// 第 二 步 

private int second(){ 
System.out.println(" 执 行 第 二 个 方法 ,,. ,"); 
return rand.nextInt(100) ; 


} 

// 第 三 个 方法 

private nt third(){ 
System.out.println(" 执 行 第 三 个 方法 ...")， 
return rand.nextInt(100); 


} 
// 软 件 安装 过 程 
public void installwizard( ){ 
int first = this.first(); 
// 根 据 first 返 回 的 结果 ， 看 是 否 需 要 执行 second 
If(first>50){ 
int second = this.second(); 


If(Second>50){ 
int third = this.third(); 
if(third >50){ 
this.first(); 
} 


将 三 个 步骤 的 访问 权限 修改 为 private， 同 时 把 InstallSoftware 中 的 方 
法 installWizad 移 动 到 Wizard 方 法 中 。 通 过 这 样 的 重 构 后 ，Wizard 类 残 只 
对 外 公布 了 一 个 public 方 法 ， 即 使 要 修改 first 方 法 的 返回 值 ， 影 啊 的 也 
仅仅 只 是 Wizard 本 号 ， 其 他 类 不 受 影响 ， 这 显示 了 类 的 高 内 聚 特性 。 


对 InstallSoftware 类 进行 少量 的 修改 ， 如 代码 清单 5-12 所 示 。 


代码 清单 5-12 修改 后 的 InstallSoftware 类 


public class InstallSoftware { 
public void installwizard(Wizard wizard)t{ 
// 直 接 调 用 


wizard.installwizard( ); 


场景 类 Client 没 有 任何 改变 ， 如 代码 清单 5-10 所 示 。 通 过 进行 重 
构 ， 类 间 的 硝 合 关系 区 弱 了 了， 结构 也 清晰 了 ， 变 更 引起 的 风险 也 变 小 
了 。 


一 个 类 公开 的 public 属 性 或 方法 越 多 ， 修 改 时 涉及 的 面 也 束 越 大 ， 
变更 引起 的 风险 扩散 也 就 越 大 。 因 此 ， 为 了 保持 朋友 类 间 的 距离 ， 在 
设计 时 需要 反复 衡量 : 是 否 还 可 以 再 减少 public 方 法 和 属性 ， 是 否 可 以 


修改 为 private、package-private 〈 包 类 型 ， 在 类 、 方 法 、 变 量 前 不 加 访 
问 权限 ， 则 默认 为 包 类 型 ) 、Pprotected 等 访问 权限 ， 是 否 可 以 加 上 final 
大 键 字 等 。 


注意 ” 迪 米 特 法 则 要 求 类 “ 羞 汐 ”一 点 ， 尽 量 不 要 对 外 公布 太 多 的 
public 方 法 和 非 静 态 的 public 变 量 ， 尺 量 内 人 级 ， 多 使 用 private、package- 
private、protected 等 访问 权限 。 


3. 是 目 己 的 束 是 目 己 的 


在 实际 应 用 中 经 常会 出 现 这 样 一 个 方法 ， 放 在 本 类 中 也 可 以 ， 放 
在 其 他 类 中 也 没有 错 ， 那 怎么 去 衡量 呢 ? 你 可 以 坚持 这 样 一 个 原则 : 
如 有 条 一 个 方法 放 在 本 类 中 ， 既 不 增加 类 间 关 系 ， 也 对 本 类 不 产生 负面 
影响 ， 那 吏 放 置 在 本 类 中 。 


4. 说 慎 使 用 Serializable 


在 实际 应 用 中 ， 这 个 问题 是 很 少 出 现 的 ， 即 使 出 现 也 会 立即 被 发 
现 并 得 到 解决 。 是 怎么 回 事 呢 ? 举 个 例子 来 说 ， 在 一 个 项 目 中 使 用 
RMI (Remote Method Invocation， 远 程 方法 调用 ) 方式 传递 一 个 VO 
(Value Object， 值 对 象 ) ， 这 个 对 象 就 必须 实现 Serializable 接 口 ( 仅 
仅 是 一 个 标志 性 接口 ， 不 需要 实现 具体 的 方法 ) ， 也 就 是 把 需要 网 络 
传输 的 对 象 进 行 序列 化 ， 否 则 就 会 出 现 NotSerializableException 有 异常 。 


突然 有 一 天 ， 客 户 端 的 VO 修改 了 一 个 属性 的 访问 权限 ， 从 private 变 更 
为 public， 访 问 权 限 扩 大 了 ， 如 琳 服 务 絮 上 没有 做 出 相应 的 变更 ， 束 会 
报 序列 化 失败 ， 殊 这 么 简单 。 但 是 这 个 问题 的 产生 应 该 属于 项 目 管理 
范 晓 ， 一 个 类 或 接口 在 客户 端 已 经 变更 了 ， 而 服务 器 端 却 没有 同步 更 
新 ， 难 道 不 是 项 目 管理 的 失职 吗 ? 


5.3 最 佳 实践 


过 米 特 法 则 的 核心 观念 束 吓 类 间 解 而， 弱 籼 合 ， 只 有 弱 籼 合 了 以 
后 ， 类 的 复 用 率 才 可 以 提高。 其 要 求 的 结果 束 是 产生 了 大 量 的 中 转 或 
跳 转 类 ， 导 致 系统 的 复杂 性 所 高， 同时 也 为 维护 市 来 了 难度 。 读 者 在 
采用 迪 米 特 法 则 时 需要 反复 权衡 ， 既 做 到 让 结构 清晰 ， 又 做 到 高 内 到 
低 耦 合 。 


不 知道 大 家 有 没有 听 过 这 样 一 个 理论 : “任何 两 个 素 不 相识 的 人 中 
间 最 多 只 隔 着 6 个 人 ， 即 只 通过 6 个 人 束 可 以 将 他 们 联系 在 一 起 ”， 这 就 
征 闭 名 的 “六 度 分 隔 理论 ”。 如 采 将 这 个 理论 应 用 到 我 们 的 项 目 中 ， 也 
忠 是 说 ， 我 和 我 要 调用 的 类 之 间 最 多 有 6 次 传递 。 呵 呵 ， 这 只 能 让 大 家 
当 个 乐子 来 看 ， 在 实际 应 用 中 ， 如 果 一 个 类 跳 转 两 次 以 上 才能 访问 到 
男 一 个 类 ， 束 需要 想 办 法 进行 重 构 了 ， 为 什么 是 两 次 以 上 呢 ? 因 为 一 
个 系统 的 成 功 不 仅仅 和 是 一 个 标准 或 是 原则 束 能 够 决定 的 ， 有 非常 多 的 
外 在 因素 决定 ， 跳 转 次 数 越 多 ， 系 统 越 复杂 ， 维 护 束 越 困 难 ， 所 以 只 
要 跳 转 不 超过 两 次 都 是 可 以 妨 受 的 ， 这 需要 具体 问题 具体 分 析 。 


迪 米 特 法 则 要 求 类 间 解 耦 ， 但 解 耦 是 有 限度 的 ， 除 非 是 计算 机 的 
最 小 单元 一 一 二 进 制 的 0 和 1。 那 才 是 完全 解 耦 ， 在 实际 的 项 目 中 ， 需 
要 适度 地 考虑 这 个 原则 ， 别 为 了 套用 原则 而 做 项 目 。 原 则 只 是 供 参 


考 ， 如 有 果 违 育 了 这 个 原则 ， 项 目 也 未 必 会 失败 ， 这 束 需 要 大 家 在 采用 
原则 时 反复 度量 ， 不 遵循 是 不 对 的 ， 严 格 执 行 束 是 “过 犹 不 及 ”。 


第 6 章 ” 开 闭 原 则 


6.1 开 闭 原则 的 定义 


在 哲学 上 ， 了 矛盾 法 则 即 对 立 统一 的 法 则 ， 十 唯物 辩证 法 的 最 根本 
法 则 。 本 章 要 讲 的 开 闭 原则 是 不 是 也 有 同样 的 重要 性 且 具 有 普通 性 
呢 ? 确实 ， 开 闭 原则 是 Java 世 界 里 最 基础 的 设计 原则 ， 它 指导 我 们 如 
何 建立 一 个 稳定 的 、 有 灵活 的 系统 ， 先 来 看 开 财 原则 的 定义 : 


Software entities like classes,modules and functions should be open 
for extension but closed for modifications. 〈 一 个 软件 实体 如 类 、 模 块 和 
函数 应 该 对 扩展 开放 ， 对 修改 关闭 。) 


初 看 到 这 个 定义 ， 可 能 会 很 迷惑 ， 对 扩展 开放 ? 开放 什么 ? 对 修 
改 关 闭 ， 怎 么 关闭 ? 没关系 ， 我 会 一 步 一 步 市 领 大 家 解 开 这 些 疑 惑 。 


我 们 做 一 件 事情 ， 或 者 选择 一 个 方向 ， 一 般 需 要 经 历 三 个 步 桑 : 
是 什么 ，Why 一 一 为 什么 ，How 一 一 怎么 做 〈 简 称 3W 原 则 ， 
How 取 最 后 一 个 w) 。 对 于 开 闭 原则 ， 我 们 也 采用 这 三 步 来 分 析 ， 即 
什么 是 开 财 原则 ， 为 什么 要 使 用 开 闭 原则 ， 怎 么 使 用 开 闭 原则 。 


What 


6.2 开 财 原则 的 庐山 真面目 


开 闭 原则 的 定义 已 经 非 第 明确 地 告诉 我 们 ， 软 件 实体 应 该 对 扩展 
开放 ， 对 修改 关闭 ， 其 含义 是 说 一 个 软件 实体 应 该 通过 扩展 来 实现 变 
化 ， 而 不 是 通过 修改 已 有 的 代码 来 实现 变化 。 那 什么 又 是 软件 实体 
呢 ? 软件 实体 包括 以 下 几 个 部 分 : 


e 项 目 或 软件 产品 中 按照 一 定 的 逻辑 规则 划分 的 模块 。 
e 抽象 和 类 。 
e 方法 。 


一 个 软件 产品 只 要 在 生命 期 内 ， 都 会 发 生变 化 ， 既 然 变化 是 一 个 
既定 的 事实 ， 我 们 惑 应 该 在 设计 时 尽量 适应 这 些 变 化 ， 以 提高 项 目的 
稳定 性 和 灵活 性 ， 真 正 实现 “拥抱 变化 ”。 开 闭 原 则 告诉 我 们 应 尽量 通 
过 扩展 软件 实体 的 行为 来 实现 变化 ， 而 不 是 通过 修改 已 有 的 代码 来 完 
成 变化 ， 它 是 为 软件 实体 的 未 来 事件 而 制定 的 对 现行 开发 设计 进行 约 
束 的 一 个 原则 。 我 们 举例 说 明 什 么 是 开 闭 原则 ， 以 书店 销售 书籍 为 
例 ， 其 类 图 如 图 6-1 所 示 。 


<<Interface>> 
IBook 


BookStore 


HString getName() 
+mt getPrice() 
+String getAuthor() 


NovelBook 
FS 


+NovelBook(Strng name, mt _price, Strng author) 


图 6-1 书店 售 书 类 图 


IBook 定 义 了 数据 的 三 个 属性 : 名称、 价格 和 作者 。 小 说 类 
NovelBook 走 一 个 具体 的 实现 类 ， 是 所 有 人 小 说 书籍 的 总 称 ，BookStore 
指 的 是 书店 ，IBook 接 口 如 代码 清单 6-1 所 示 。 


代码 清单 6-1 书籍 接口 


public interface IBook { 


public String getName(); 

// 书 籍 有 售 价 

public int getpPrice() ， 
者 


public String getAuthor(); 


目前 书店 只 出 千 小 说 类 书籍 ， 小 说 类 如 代码 清单 6-2 所 示 。 


代码 清单 6-2 小 说 类 


public class NovelBook implements IBook { 
// 书 籍 名 称 
private String name; 
/ /书籍 的 价格 
private int price; 
// 书 籍 的 作者 


private String author 
// 通 过 构造 画 数 传递 书籍 数据 


public NovelBook(String _name,int _price,String _author)t{ 


this.name = _name; 
this.price = _price; 
this.author = _author; 
} 
// 获 得 作者 是 谁 


public String getAuthor( ) { 
return this.author ， 


} 

// 书 籍 叫 什么 名 字 

public String getName() { 
return this.name; 


} 

// 获 得 书籍 的 价格 

public int getPrice() { 
return this.price; 

} 


注意 ”我 们 把 价格 定义 为 int 类 型 并 不 是 错误 ， 在 非 金融 类 项 目 中 
对 货币 处 理 时 ， 一 般 取 2 位 精度 ， 通 常 的 设计 方法 是 在 运算 过 程 中 扩大 
100 倍 ， 在 需要 展示 时 再 缩小 100 倍 ， 减 少 精 度 带 来 的 误差 。 


书店 售 书 的 过 程 如 代码 清单 6-3 所 示 。 


代码 清单 6-3 书店 售 书 类 


public class BookStore { 
private final static ArrayList<IBook> bookList = new 
ArrayList<IBook>(); 
//static 静 态 模 块 初始 化 数据 ， 实 际 项 目 中 一 般 是 由 持久 层 完 成 
statict{ 
bookList,add(new NovelBook(" 天 龙 八 部 ", 3200, "金庸 ")); 
bookList,add(new NovelBook(" 巴 黎 圣 母 院 ", 5600, "十 


二 
bookList,add(new NovelLBook( "悲惨 世界 ", 3500," 雨 果 ")); 
bookList,add(new NovelLBook(" 人 金瓶 梅 ",4300," 兰 陵 笑 笑 


DT 


sh 


} 
// 模 拟 书店 买书 
public static void main(String[] args) { 
NumberFormat formatter = 
NumberFormat .getCurrencyInstance( ) ; 
formatter.setMaximumFractionDigits(2); 
System.out.printin("----------- 书店 卖 出 去 的 书籍 记录 如 


for(IBook book:bookList)t{ 
System,.out.println(" 书 籍 名 称 : " + 
book .getName( )+"\t 书 籍 作者 : " + 
book .getAuthor()+"\t 书 籍 价格 : "+ formatter.format 
(book.getPrice()/ 
100.0)+" 元 "); 
} 


在 BookStore 中 声明 了 一 个 静态 模块 ， 实 现 了 数据 的 初始 化 ， 这 部 
分 应 该 是 从 持久 层 产 生 的 ， 由 持久 层 框 架 进行 管理 ， 运 行 结 琳 如 下 : 


书籍 名 称 ， 天 龙 八 部 。 书籍 作者 : 金良 书籍 价格 ， 竺 25.60 元 
书籍 名 称 ， 巴黎 圣母 院 “书籍 作者 ; 雨 果 书籍 价格 :至 50.40 元 
书籍 名 称 : 悲惨 世界 书籍 作者 : 两 果 书籍 价格 : 至 28.00 元 


书籍 名 称 : 金瓶 梅 书籍 作者 : 兰 陵 笑 笑 生 ”书籍 价格 : 至 38.70 元 


项 目 投产 了 ， 书 籍 正常 销售 出 去 ， 书 店 也 说 利 了 。 从 2008 年 开 
始 ， 全 球 经 济 开 始 下 请 ， 对 零售 业 影响 比较 大 ， 书 店 为 了 生存 开始 打 
折 销 售 : 所 有 40 元 以 上 的 书籍 9 折 销 售 ， 其 他 的 8 折 销 售 。 对 已 经 投产 
的 项 目 来 说 ， 这 就 是 一 个 变化 ， 我 们 应 该 如 何 应 对 这 样 一 个 需求 变 
化 ? 有 如 下 三 种 方法 可 以 解决 这 个 问题 : 


e 修改 接口 


在 IBook 上 新 增加 一 个 方法 getOffPrice()， 专 门 用 于 进行 打折 处 理 ， 
所 有 的 实现 类 实现 该 方法 。 但 是 这 样 修改 的 后 果 就 是 ， 实 现 类 
NovelBook 要 修改 ，BookStore 中 的 main 方 法 也 修改 ， 同 时 IBook 作 为 接 
口 应 该 是 稳定 且 可 靠 的 ， 不 应 该 经 常 发 生变 化 ， 否 则 接口 作为 契约 的 
作用 就 失去 了 效能 。 因 此 ， 该 方案 否定 。 


e 修改 实现 类 


修改 NovelBook 类 中 的 方法 ， 直 接 在 getPrice() 中 实现 打折 处 理 ， 好 
办 法 ， 我 相信 大 家 在 项 目 中 经 常 使 用 的 就 古 这 样 的 办 法 ， 通 过 class 文 
件 替换 的 方式 可 以 完成 部 分 业务 变化 (或 是 缺陷 修复 ) 。 该 方法 在 项 
目 有 明确 的 革 程 (团队 内 约束 ) 或 优良 的 架构 设计 时 ， 是 一 个 非常 优 
秀 的 方法 ， 但 是 该 方法 还 是 有 缺陷 的 。 例 如 采购 书籍 人 员 也 十 要 看 价 
格 的 ， 由 于 该 方法 已 经 实现 了 打折 处 理 价格 ， 因 此 采购 人 员 看 到 的 也 


是 打折 后 的 价格 ， 会 因 信息 不 对 称 而 出 现 决 策 失 误 的 情况 。 因 此 ， 该 
方案 也 不 是 一 个 最 优 的 方案 。 


e 通过 扩展 实现 变化 


增加 一 个 子 类 OffNovelBook， 禾 写 getPrice 方 法 ， 高 层次 的 模块 
(也 就 是 static 静 态 模 块 区 ) 通过 OffNovelBook 类 产生 新 的 对 象 ， 完 成 
业务 变化 对 系统 的 最 小 化 开发 。 好 办 法 ， 修 改 也 少 ， 风 险 也 小 ， 修 改 
后 的 类 图 如 图 6-2 所 示 。 


BookStore 


+String getName() 
+int getPrice() 
+String getAuthor() 


NovelBook 
| 


+NovelBook(Strng name, mt price, Strmg author) 


OffNovelBook 


+nt getPrice() 


履 写 getPrice 方 法 


图 6-2 扩展 后 的 书店 售 书 类 图 


OffNovelBook 类 继承 了 NovelBook， 并 禾 写 了 getPrice 方 法 ， 不 修改 
原 有 的 代码 。 新 增加 的 子 类 OffNovelBook 如 代码 清单 6-4 所 示 。 
代码 清单 6-4 打折 销售 的 小 说 类 


public class OffNovelBook extends NovelBook { 
public OffNovelBook(String _name,int _price,String _author) 


super(_name,_price,_author); 


} 
// 履 写 销售 价格 
Q@Override 
public int getPrice( ){ 
// 原 价 
int selfPrice = super.getPricel(); 
int offPrice=0; 
if(selfPrice>4000){ // 原 价 大 于 40 元 ， 则 打 9 折 
offPrice = selfPrice * 90 /100; 


}elsef{ 
offPrice = SelfPrice * 80 /100; 


return offPrice; 


很 简单 ， 仅 仅 履 写 了 getPrice 方 法 ， 通 过 扩展 完成 了 新 增加 的 业 
务 。 书 店 类 BookStore 需 要 依赖 子 类 ， 代 码 稍 作 修 改 ， 如 代码 清单 6-5 所 


修 ° 


代码 清单 6-5 书店 打折 销售 类 


public class BookStore { 
private final static ArrayList<IBook> bookList = new 
ArrayList<IBook>(); 
//static 静 态 模 块 初始 化 数据 ， 实 际 项 目 中 一 般 是 由 持久 层 完 成 
statict{ 
bookList,add(new 0ffNovelBook(" 天 龙 八 部 ", 3200, " 金 


良 ") ) ; 

bookList,add(new 0ffNovelBook(" 巴 黎 对 和 母 院 ", 5600, "两 
有 果 ") ) ; 

bookList,add(new OffNove1LBook(" 翡 惨 世界 " ,3500, "两 
二 ”让 

bookList,add(new offNove1Book(" 金 瓶 梅 ", 4300," 兰 陵 笑 笑 
生 ")); 


} 

// 模 拟 书店 买书 
public static void main(String[] args) { 
NumberFormat formatter = 

NumberFormat .getCurrencyInstance( ) ; 
formatter.setMaximumFractionDigits(2); 


System.out.println("----------- 书店 卖 出 去 的 书籍 记录 如 


for(IBook book:bookList)t{ 
System.out.println(" 书 籍 名 称 : " + 
book ,getName( )+"\t 书 籍 作者 : " + book.getAuthor()+“"\t 书 籍 价格 : " + 
formatter .format (book.getPrice()/100.0)+" 元 "); 


】 
} 
} 

运行 结果 如 下 所 示 。 

书店 卖 出 去 的 书籍 记录 如 下 -------------…- 
书籍 名 称 ， 天 龙 八 部 ”书籍 作者 金良 书籍 价格 ， 鞋 25.60 元 
书籍 名 称 ， 巴 黎 圣母 院 “书籍 作者 ， 雨 果 书籍 价格 ， 半 50.40 元 
书籍 名 称 ， 翡 惨 世 界 。 ”书籍 作者 ， 雨 果 书籍 价格 ， 鞋 28.00 元 
书籍 名 称 ， 金 瓶 梅 。 ”书籍 作者 ， 兰 陵 笑 笑 生 。” 书籍 价格 ， 竺 38.70 元 


OK， 打 折 销 售 开 发 完成 了 。 看 到 这 里 ， 各 位 可 能 有 想法 了 : 增加 
了 一 个 OffNoveBook 类 后 ， 你 的 业务 逻辑 还 是 修改 了 ， 你 修改 了 static 静 
态 模块 区 域 。 这 部 分 确实 修改 了 ， 该 部 分 属于 高 层次 的 模块 ， 是 由 持 
久 层 产生 的 ， 在 业务 规则 改变 的 情况 下 高 层 模块 必须 有 部 分 改变 以 适 
应 新 业务 ， 改 变 要 尽量 地 少 ， 防 止 变 化 风险 的 扩散 。 


注意 开 闭 原则 对 扩展 开放 ， 对 修改 关闭 ， 并 不 意味 着 不 做 任何 
修改 ， 低 层 模 块 的 变更 ， 必 然 要 有 高 层 模 块 进行 而 合 ， 否 则 就 是 一 个 
孤立 无 意义 的 代码 片段 。 


吨 


我 们 可 以 把 变化 归纳 为 以 下 三 种 类 型 : 


e 逻辑 变化 


只 变化 一 个 逻辑 ， 而 不 涉及 其 他 模块 ， 比 如 原 有 的 一 个 算法 是 
a*bt+c， 现 在 需要 修改 为 a*b*c， 可 以 通过 修改 原 有 类 中 的 方法 的 方式 来 
完成 ， 前 提 条 件 是 所 有 依赖 或 天 联 类 都 按照 相同 的 逻辑 处 理 。 


e 于 模块 变化 


一 个 模块 变化 ， 会 对 其 他 的 模块 产生 影响 ， 特 别 是 一 个 低层 次 的 
模块 变化 必然 引起 高 层 模块 的 变化 ， 因 此 在 通过 扩展 完成 变化 时 ， 高 
层次 的 模块 修改 是 必然 的 ， 刚 刚 的 书籍 打折 人 处理 束 古 类 似 的 处 理 模 
块 ， 该 部 分 的 变化 甚至 会 引起 界面 的 变化 。 


e 可 见 视图 变化 


可 见 视图 是 提供 给 客户 使 用 的 界面 ， 如 JSP 程 序 、Swing 界 面 等 ， 
该 部 分 的 变化 一 般 会 引起 连锁 反应 (特别 是 在 国内 做 项 目 ， 做 欧美 的 
外 包 项 目 一 般 不 会 影响 太 大 ) 。 如 果 仅 仅 是 界面 上 按钮 、 文 字 的 重新 
排 布 倒是 简单 ， 最 司空 见 惯 的 是 业务 耦合 变化 ， 什 么 意思 呢 ? 一 个 展 
示 数 据 的 列表 ， 按 照 原 有 的 需求 是 6 列 ， 突 然 有 一 天 要 增加 1 列 ， 而 且 
这 一 列 要 跨 N 张 表 ， 处 理 M 个 逻辑 才能 展现 出 来 ， 这 样 的 变化 是 比较 人 怒 


怖 的 ， 但 还 是 可 以 通过 扩展 来 完成 变化 ， 这 束 要 看 我 们 原 有 的 设计 是 


我 们 再 来 回顾 一 下 书店 销售 书籍 的 程序 ， 首 先是 我 们 有 一 个 还 算 
灵活 的 设计 (不 灵活 是 什么 样子 ? BookStore 中 所 有 使 用 到 IBook 的 地 方 
全 部 修改 为 实现 类 ， 然 后 再 扩展 一 个 ComputerBook 书 籍 ， 你 束 知 道 什 
么 是 不 灵活 了 ) ; 然后 有 一 个 需求 变化 ， 我 们 通过 扩展 一 个 子 类 拥抱 
了 变化 ， 最 后 把 于 类 投入 运行 环境 中 ， 新 逻辑 正式 投产 。 通 过 分 析 ， 
我 们 发 现 并 没有 修改 原 有 的 模块 代码 ，IBook 接 口 没 有 改变 ， 
NovelBook 尖 没有 改变 ， 这 属于 已 有 的 业务 代码 ， 我 们 保持 了 历史 的 纯 
滞 性 。 放 弃 修改 历史 的 想法 吧 ， 一 个 项 目的 基本 路 径 应 该 是 这 样 的 : 
项 目 开 发 、 重 构 、 测 试 、 投 产 、 运 维 ， 其 中 的 重 构 可 以 对 原 有 的 设计 
和 代码 进行 修改 ， 运 维 尽量 减少 对 原 有 代码 的 修改 ， 保 持 历史 代码 的 
纯洁 性 ， 提 高 系统 的 稳定 性 。 


6.3 为 什么 要 采用 开 闭 原则 


每 个 事物 的 诞生 都 有 它 存在 的 必要 性 ， 存 在 即 合理 ， 那 开 闭 原则 
的 存在 也 是 合理 的 ， 为 什么 这 么 说 呢 ? 


百 完 ， 开 闭 原则 非常 著名 ， 只 要 是 做 面 同 对 象 编程 的 ， 表 管 十 什 
么 语言 ，Java 也 好 ，C++ 也 好 ， 或 者 是 Smalltalk， 在 开发 时 都 会 提 及 开 
闭 原 则 。 


其 次 ， 开 闭 原则 是 最 基础 的 一 个 原则 ， 前 五 革 市 介绍 的 原则 都 古 
开 闭 原则 的 具体 形态 ， 也 融 是 说 前 五 个 原则 束 是 指导 设计 的 工具 和 方 
法 ， 而 开 闭 原则 才 征 其 精神 领袖 。 换 一 个 角度 来 理解 ， 依 照 Java 语 言 
的 称谓 ， 开 闭 原则 是 抽象 类 ， 其 他 五 大 原则 是 具体 的 实现 类 ， 开 闭 原 
则 在 面向 对 象 设计 领域 中 的 地 位 束 类 似 于 牛顿 第 一 定律 在 力学 、 义 股 
定律 在 几何 学 、 质 能 方程 在 狭义 相对 论 中 的 地 位 ， 其 地 位 无 人 能 


最 后 ， 开 闭 原 则 是 非常 重要 的 ， 可 通过 以 下 几 个 方面 来 理解 其 重 
归 必 2 


1. 开 闭 原则 对 测试 的 影响 


所 有 已 经 投产 的 代码 都 是 有 意义 的 ， 并 且 都 受 系 统 规则 的 约束 ， 
这 样 的 代码 都 要 经 过 “ 千 锤 百 炼 ”的 测试 过 程 ， 不 仅 保 证 逻辑 是 正确 


的 ， 还 要 保证 苛刻 条 件 (高 压力 、 异 常 、 错 误 ) 下 不 产生 “有 毒 代 
码 ” (Poisonous Code) ， 因 此 有 变化 提出 时 ， 我 们 就 需要 考虑 一 下 ， 
原 有 的 健壮 代码 是 否 可 以 不 修改 ， 仅 仅 通过 扩展 实现 变化 呢 ? 人 否则， 
吕 需 要 把 原 有 的 测试 过 程 回 党 一 届 ， 需 要 进行 单元 测试 、 功 能 测试 、 
集成 测试 甚至 是 验收 测试 ， 现 在 虽然 在 大 力 提倡 目 动 化 测试 工具 ,但 
苹 仍 然 代 替 不 了 人 工 的 测试 工作 。 


以 上 面 提 到 的 书店 售 书 为 例 ，IBook 接 口 写 完 了 ， 实 现 类 
NovelBook 也 写 好 了 ， 我 们 需要 写 一 个 测试 类 进行 测试 ， 测 试 类 如 代 
码 清单 6-6 所 示 。 


代码 清单 6-6 小 说 类 的 单元 测试 


public class NovelBookTest extends TestCase { 
private String name = "平凡 的 世界 " ; 
private int price = 6000 
private String author = "路 遥 " ， 
private IBook novelBook = new 
NovelBook (name, price,author ) ， 
// 测 试 getPrice 方 法 
public void testGetPrice() { 
// 原 价 销售 ， 根 据 输入 和 输出 的 值 是 否 相等 进行 断言 
super.assertEquals(this.price, 
this.novelBook.getPrice( )); 


he 


单元 测试 通过 ， 显 示 绿 条 。 在 单元 测试 中 ， 有 一 句 非常 有 名 的 
话 ， 叫 做 "Keep the bar green to keep the code clean"， 即 保持 绿 条 有 利于 
代码 整洁 ， 这 是 什么 意思 呢 ? 绿 条 束 是 Junit 运 行 的 两 种 结 采 中 的 一 


种 : 要 么 是 红 条 ， 单 元 测试 失败 ; 要 么 是 绿 条 ， 单 元 测试 通过 。 一 个 
方法 的 测试 方法 一 般 不 少 于 3 种 ， 为 什么 呢 ? 首 先是 正常 的 业务 逻辑 要 
保证 测试 到 ， 其 次 是 边界 条 件 要 测试 到 ， 然 后 是 异常 要 测试 到 ， 比 较 
重要 的 方法 的 测试 方法 甚至 有 十 多 种 ， 而 且 单 元 测试 是 对 类 的 测试 ， 

类 中 的 方法 耦合 是 允许 的 ， 在 这 样 的 条 件 下 ， 如 果 再 想 着 通过 修改 一 
个 方法 或 多 个 方法 代码 来 完成 变化 ， 基 本 上 束 是 病人 遂 梦 ， 该 类 的 所 
有 测试 方法 都 要 重 构 ， 想 象 一 下 你 在 一 堆 你 并 不 熟悉 的 代码 中 进行 重 
构 时 的 感觉 吧 ! 


在 书店 售 书 的 例子 中 ， 增 加 了 一 个 打折 销售 的 需求 ， 如 采 我 们 直 
接 修 改 getPrice 方 法 来 实现 业务 需求 的 变化 ， 那 惑 要 修改 单元 测试 类 。 
想 想 看 ， 我 们 举 的 这 个 例子 是 非常 稍 单 的 ， 如 采 是 一 个 复杂 的 逻辑 ， 
你 的 测试 类 就 要 修改 得 面目 全 非 。 还 有 ， 在 实际 的 项 目 中 ， 一 个 类 一 
般 只 有 一 个 测试 类 ， 其 中 可 以 有 很 多 的 测试 方法 ， 在 一 堆 本 来 束 很 复 
杂 的 断言 中 进行 大 量 修改 ， 难 免 会 出 现 测 试 遗漏 情况 ， 这 是 项 目 经 理 
很 难 容 妨 的 事情 。 


所 以 ,我们 需要 通过 扩展 来 实现 业务 逻辑 的 变化 ， 而 不 是 修改 。 
上 面 的 例子 中 通过 增加 一 个 子 类 OffNovelBook 来 完成 了 业务 需求 的 变 
化 ， 这 对 测试 有 什么 好 处 呢 ? 我 们 重新 生成 一 个 测试 文件 
OffNovelBookTest， 然 后 对 getPrice 进 行 测试 ， 单 元 测试 是 孤立 测试 ， 


只 要 保证 我 提供 的 方法 正确 就 成 了 ， 其 他 的 我 不 管 ， 
OffNovelBookTest 如 代码 清单 6-7 所 示 。 


代码 清单 6-7 打折 销售 的 小 说 类 单元 测试 


public class OffNovelBookTest extends TestCase { 

private IBook below40NovelBook = new 0ffNovelBook(" 平 凡 的 世 
有 下" 3000, 1 路 还" ) 有 
private IBook above40NovelBook = new 0ffNovelBook(" 平 凡 的 世 
界 ",6000, "路 遥 " ) ; 

// 测 试 低 于 46 元 的 数据 是 否 是 打 8 折 

public void testGetPriceBelow40() { 

super.assertEquals(2400, 

this.below40NovelBook.getPrice( )); 


于 


} 
// 测 试 大 于 40 的 书籍 是 否 是 打 9 折 
public void testGetPriceAbove40( ){ 
super.assertEquals(5400, 
this.above40NovelBook.getPrice( )); 


} 


新 增加 的 类 ， 痢 增加 的 测试 方法 ， 只 要 保证 独 增 加 类 十 正确 的 惑 
可 以 了 。 


2. 开 闭 原则 可 以 提高 复 用 性 


在 面 问 对 象 的 设计 中 ， 所 有 的 逻辑 都 是 从 原子 逻辑 组 合 而 来 的 ， 
而 不 是 在 一 个 类 中 独立 实现 一 个 业务 逻辑 。 只 有 这 样 代 码 才 可 以 复 
用 ,粒度 越 小 ， 被 复 用 的 可 能 性 束 越 大 。 那 为 什么 要 复 用 呢 ? 减少 代 
码 量 ， 避 人 免 相 同 的 逻辑 分 散在 多 个 角落 ， 避 人 免 日 后 的 维护 人 员 为 了 修 
改 一 个 微小 的 缺陷 或 增加 新 功能 而 要 在 整个 项 目 中 到 处 查找 相关 的 代 


码 ， 然 后 发 出 对 开发 人 员 "“ 极 度 失望 ”的 感慨 。 那 怎么 才能 提高 复 用 率 
呢 ? 缩小 逻辑 粒度 ， 直 到 一 个 逻辑 不 可 再 拆 分 为 止 。 


3. 开 闭 原则 可 以 提高 可 维护 性 


一 款 软 件 投产 后 ， 维 护 人 员 的 工作 不 仅仅 是 对 数据 进行 维护 ， 还 
可 能 要 对 程序 进行 扩展 ， 维 护 人 员 最 乐意 做 的 事情 就 古 扩 展 一 个 类 ， 
而 不 是 修改 一 个 类 ， 表 管 原 有 的 代码 写 得 多 么 优秀 还 是 多 么 糟 烷 ， 让 
维护 人 员 读 慌 原 有 的 代码 ， 然 后 再 修改 ， 是 一 件 很 痛 匣 的 事情 ， 不 要 
让 他 在 原 有 的 代码 海洋 里 游 飞 完 毕 后 再 修改 ， 那 是 对 维护 人 员 的 一 种 
折磨 和 摧残 。 


4. 面向 对 象 开发 的 要 求 


万 物 宵 对 象 ， 我 们 需要 把 所 有 的 事物 都 抽象 成 对 象 ， 然 后 针对 对 
象 进行 操作 ， 但 是 万 物 氏 运动 ， 有 运动 束 有 变化 ， 有 变化 殉 要 有 寅 略 
去 应 对 ， 怎 么 快速 应 对 呢 ? 这 束 需 要 在 设计 之 初 考 虑 到 所 有 可 能 变化 
的 因素 ， 然 后 留 下 接口 ， 等 竺 "可 能 ”转变 为 "现实 ”。 


6.4 如 何 使 用 开 财 原则 


开 闭 原则 是 一 个 非常 虚 的 原则 ， 前 面 5 个 原则 是 对 开 闭 原则 的 具体 
解释 ,但 是 开 闭 原则 并 不 局 限于 这 么 多 ， 它 “ 虚 ” 得 没有 边界 ， 讽 像 “ 好 
好 学 习 ， 天 天 向 上 ”的 口号 一 样 ， 告 诉 我 们 要 好 好 学 习 ， 但 是 学 什么 ， 
怎么 学 并 没有 告诉 我 们 ， 需 要 去 体会 和 掌握 ， 开 闭 原则 也 是 一 个 口 
号 ， 那 我 们 怎么 把 这 个 口号 应 用 到 实际 工作 中 呢 ? 


1. 抽象 约束 


抽象 是 对 一 组 事物 的 通用 描述 ， 没 有 具体 的 实现 ， 也 就 表示 它 可 
以 有 非常 多 的 可 能 性 ， 可 以 跟随 需求 的 变化 而 变化 。 因 此 ， 通 过 接口 
或 抽象 类 可 以 约束 一 组 可 能 变化 的 行为 ， 并 且 能 够 实现 对 扩展 开放 ， 
其 包含 三 层 含义 ， 第 一 ， 通 过 接口 或 抽象 类 约束 扩展 ， 对 扩展 进行 边 
界限 定 ， 不 允许 出 现在 接口 或 抽象 类 中 不 存在 的 public 方 法 ， 第 二 ， 参 
数 类 型 、 引 用 对 象 尽量 使 用 接口 或 者 抽象 类 ， 而 不 是 实现 类 ; 第 三 
抽象 层 尽量 保持 稳定 ， 一 旦 确定 即 不 允许 修改 。 还 是 以 书店 为 例 ， 目 
前 只 是 销售 小 说 类 书籍 ， 单 一 经 营 毕 竟 是 有 风险 的 ， 于 是 书店 狐 增 加 
了 计算 机 书籍 ， 它 不 仅 包含 书籍 名 称 、 作 者 、 价 格 等 信息 ， 还 有 一 个 
独特 的 属性 : 面 回 的 是 什么 领域 ， 也 殉 是 它 的 范围 ， 比 如 是 和 编程 语 
言 相 关 的 ， 还 是 和 数据 库 相 天 的 ， 等 等 ， 修 改 后 的 类 图 如 图 6-3 所 示 。 


<<interface>> 
IBook 


+Strng getName() 
+int getPrice() 
+Strng getAuthor() 


<<mterface>> 
IComputerBook 


BookStore 
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NovelBook 


= ~ =- -= 
+String getScope() 


全 


ComputerBook 


图 6-3 增加 业务 品种 后 的 书店 售 书 类 图 


增加 了 一 个 接口 IComputerBook 和 实现 类 Computer- Book， 而 
BookStore 不 用 做 任何 修改 瓯 可 以 完成 书店 销售 计算 机 书籍 的 业务 。 计 
算 机 书籍 接口 如 代码 清单 6-8 所 示 。 


代码 请 单 6-8 计算 机 书籍 接口 


public interface IComputerBook extends IBookt{ 
// 计 算 机 书籍 是 有 一 个 范围 
public String getScope() ; 


很 简单 ， 计 算 机 书籍 增加 了 一 个 方法 ， 就 是 获得 该 书籍 的 范围 ， 
同时 继承 IBook 接 口 ， 毕 竟 计 算 机 书籍 也 是 书籍 ， 其 实现 如 代码 清单 6- 
9 所 示 。 


代码 清单 6-9 计算 机 书籍 类 


public class ComputerBook implements IComputerBook { 

private String name; 

private String scope; 

private String author; 

private int price; 

public ComputerBook(String _name,int _price,String 
_author,String _scope)t{ 

this.name=_name; 


this.price = _price; 
this.author = _author ， 
this.scope = _scope; 


. 
public String getScope() { 
return this.scope; 


} 
public String getAuthor() { 
return this.author; 


} 
public String getName() { 
return this.name; 


public int getPrice() { 
return this.price; 
} 


这 也 很 简单 ， 实 现 IComputerBook 吏 可 以 ， 而 BookStore 类 没有 做 
任何 的 修改 ， 只 是 在 static 静 态 模 块 中 增加 一 条 数据 ， 如 代码 清单 6-10 
所 示 。 


代码 清单 6-10 书店 销售 计算 机 书籍 


public class BookStore { 
private final static ArrayList<IBook> bookList = new 
ArrayList<IBook>(); 
//static 静 态 模 块 初始 化 数据 ， 实 际 项 目 中 一 般 是 由 持久 层 完 成 
statict{ 
bookList.add(new NovelBook(" 天 龙 八 部 ", 3200, "金庸 ") )， 
bookList.add(new NovelBook(" 巴 黎 圣 母 院 ", 5600, " 雨 


术 "))， 
bookList.add(new NovelBook(" 悲 惨 世 界 ", 3500," 雨 果 ") ) 
bookList.add(new NovelBook( "金瓶 梅 ", 4300," 兰 陵 笑 笑 
二 六 


// 增 加 计算 机 书籍 
bookList.add(new ComputerBook("Think in 
Java", 4300, "Bruce Eckel", "编程 语言 " ) ) ， 


} 
// 模 拟 书店 卖 书 
public static void main(String[|] args) { 
NumberFormat formatter = 
NumberFormat ,getCurrencyInstance( ); 


System,out,.println("----------- 书店 卖 出 去 的 书籍 记录 如 


for(IBook book:bookList)t{ 
System.out.printlLn(" 书 籍 名 称 : " + 

book .getName( )+"\t 书 籍 作 者 : " + book,.getAuthor()+ "Nt 书籍 价格 : " + 

formatter .format (book.getPrice()/100.0)+" 元 "); 


} 


书店 开始 销售 计算 机 书籍 ， 运 行 结 末 如 下 所 示 。 


书籍 名 称 : 天 龙 八 部 书籍 作者 : 金良 书籍 价格 : 至 32.00 元 
书籍 名 称 : 巴黎 圣母 院 书籍 作者 : 两 采 书籍 价格 : 于 56.00 元 
书籍 名 称 :; 悲惨 世界 书籍 作者 : 两 采 书籍 价格 ， 竺 35.00 元 
书籍 名 称 : 金瓶 梅 书籍 作者 : 兰 陵 笑 笑 生 ”书籍 价格 ， 革 43.00 元 


书籍 名 称 ，Think in Java 书籍 作者 : Bruce Eckel 书籍 价格 : 于 43.00 元 


如 果 我 是 负责 维护 的 ， 我 就 非常 乐意 做 这 样 的 事情 ， 简 单 而 且 不 
需要 与 其 他 的 业务 进行 灶 合 。 我 唯一 需要 做 的 事情 就 是 在 原 有 的 代码 
上 添砖加瓦 ， 然 后 就 可 以 实现 业务 的 变化 。 我 们 来 看 看 这 段 代码 有 哪 
几 层 含义 。 


首先 ，CompnuterBook 类 必须 实现 IBook 的 三 个 方法 ， 是 通过 
IComputerBook 接 口传 递 进 来 的 约束 ， 也 就 是 我 们 制定 的 I[Book 接 口 对 
扩展 类 ComputerBook 产 生 了 约束 力 ， 正 是 由 于 该 约束 力 ，BookStore 类 
才 不 需要 进行 大 量 的 修改 。 


其 次 ， 如 果 原 有 的 程序 设计 采用 的 不 是 接口 ， 而 是 实现 类 ， 那 会 
出 现 什 么 问题 呢 ? 我 们 把 BookStore 类 中 的 私有 变量 bookList 修 改 一 
下 ， 如 下 面 的 代码 所 示 。 


private final static ArrayList<NovelBook> bookList = new 
ArrayList<NovelBook>( ); 


把 原 有 IBook 的 依赖 修改 为 对 NovelBook 实 现 类 的 依赖 ， 想 想 看 ， 
我 们 这 次 的 扩展 是 否 还 能 继续 下 去 呢 ? 一 旦 这 样 设计 ， 我 们 束 根 本 没 
有 办 法 扩展 ， 需 要 修改 原 有 的 业务 逻辑 (也 就 是 main 方 法 ) ， 这 样 的 
扩展 基本 上 就 是 形同虚设 。 


最 后 ， 如 果 我 们 在 IBook 上 增加 一 个 方法 getScope， 是 否 可 以 呢 ? 
是 不 可 以 ， 因 为 原 有 的 实现 类 NovelBook 已 经 在 投产 运行 中 ， 它 


答案 
不 需要 该 方法 ， 而 且 接口 是 与 其 他 模块 交流 的 契约 ， 修 改 契 约 就 等 于 


让 其 他 模块 修改 。 因 此 ， 接 口 或 抽象 类 一 旦 定义 ， 殊 应 该 立即 执行 ， 
不 能 有 修改 接口 的 思想 ， 除 非 是 彻底 的 大 返工 。 


所 以 ， 要 实现 对 扩展 开放 ， 首 要 的 前 提 条 件 束 是 抽象 约束 。 


2. 元 数据 (metadata) 控制 模块 行为 


编程 是 一 个 很 苦 很 累 的 活 ， 那 怎么 才能 减轻 我 们 的 压力 呢 ? 管 案 
是 尽量 使 用 元 数据 来 控制 程序 的 行为 ， 减 少 重复 开发 。 什 么 是 元 数 
据 ? 用 来 描述 环境 和 数据 的 数据 ， 通 俗 地 说 就 是 配置 参数 ， 参 数 可 以 
从 文件 中 获得 ， 也 可 以 从 数据 库 中 获得 。 举 个 非常 简单 的 例子 ，login 
方法 中 提供 了 这 样 的 逻辑 ， 先 检查 IP 地 址 是 否 在 允许 访问 的 列表 中 ， 
然后 再 决定 是 否 需要 到 数据 库 中 验证 密码 (如 果 采 用 SSH 架 构 ， 则 可 
以 通过 Struts 的 拦截 器 来 实现 ) ， 该 行为 就 是 一 个 典型 的 元 数据 控制 模 
块 行为 的 例子 ， 其 中 达到 极致 的 就 是 控制 反 转 (Inversion of 
Control) ， 使 用 最 多 的 就 是 Spring 容 器 ， 在 SpringContext 配 置 文件 
中 ， 基 本 配置 如 代码 清单 6-11 所 示 。 


代码 清单 6-11 SpringContext 的 基本 配置 文件 


<bean id="father" class="xxx.xxx.xxx.Father" /> 
<bean id="xx" class="xXXX.XXXx.Xxx.xxx"> 

<property name="biz" ref="father"></property> 
</bean> 


然后 ， 通 过 建立 一 个 Father 类 的 子 类 Son， 完 成 一 个 新 的 业务 ， 同 
时 修改 SpringContext 文 件 ， 修 改 后 的 文件 如 代码 清单 6-12 所 示 。 


代码 清单 6-12 扩展 后 的 SpringContext 配 置 文件 


<bean id="son" class="xxx.xxx.xxx.Son" /> 
<bean id="xx" class="XXX.XXXx.XXxx.xxx"> 

<property name="biz" ref="son"></property> 
</bean> 


通过 扩展 一 个 子 类 ， 修 改 配置 文件 ， 完 成 了 业务 变化 ， 这 也 是 采 
用 框架 的 好 处 。 


3. 制定 项 目 章 程 


在 一 个 团队 中 ， 建 立项 目 章程 是 非常 重要 的 ， 因 为 章程 中 指定 了 
所 有 人 员 都 必须 遵守 的 约定 ， 对 项 目 来 说 ， 约 定 优 于 配置 。 相 信 大 家 
都 做 过 项 目 ， 会 发 现 一 个 项 目 会 产生 非常 多 的 配置 文件 。 举 个 简单 的 
例子 ， 以 SSH 项 目 开 发 为 例 ， 一 个 项 目 中 的 Bean 配 置 文 件 束 非常 多 ， 
管理 非常 硫 烦 。 如 采 和 需要 扩展 ， 残 需要 增加 子 类 ， 并 修改 
SpringContext 文 件 。 然 而 ， 如 采 你 在 项 目 中 指定 这 样 一 个 章程 : 所 有 
的 Bean 都 自动 注入 ， 使 用 Annotation 进 行 装 配 ， 进 行 扩展 时 ， 甚 至 只 
用 写 一 个 子 类 ， 然 后 由 持久 层 生 成 对 象 ， 其 他 的 都 不 需要 修改 ， 这 就 
需要 项 目 内 约束 ， 每 个 项 目 成 员 都 必须 遵守 ， 该 方法 需要 一 个 团队 有 
较 高 的 目 沉 性， 需要 一 个 较 长 时 间 的 磨合 ， 一 旦 项 目 成 员 痢 熟悉 这 样 


的 规则 ， 比 通过 接口 或 抽象 类 进行 约束 效率 更 高 ， 而 且 扩 展 性 一 点 也 
没有 减少 。 


4. 封 效 变 化 


对 变化 的 封装 包含 两 层 合 义 : 第 一 ， 将 相同 的 变化 封 疼 到 一 个 接 
口 或 抽象 类 中 ， 第 二 ， 将 不 同 的 变化 封 狠 到 不 同 的 接口 或 抽象 类 中 ， 
不 应 该 有 两 个 不 同 的 变化 出 现在 同一 个 接口 或 抽象 类 中 。 封 装 变化 ， 
也 就 是 受 保护 的 变化 (protected variations) ， 找 出 预计 有 变化 或 不 稳 
定 的 点 ， 我 们 为 这 些 变化 点 创建 稳定 的 接口 ， 准 确 地 讲 是 封 冯 可 能 发 
生 的 变化 ， 一 旦 预测 到 或 “第 六 感 ” 发 觉 有 变化 ， 吏 可 以 进行 封装 ，23 
个 设计 模式 都 是 从 各 个 不 同 的 角度 对 变化 进行 封装 的 ， 我 们 会 在 各 个 
模式 中 逐步 讲解 。 


6.5 最 佳 实践 


软件 设计 最 大 的 难题 就 是 应 对 需求 的 变化 ， 但 是 纷繁 复杂 的 需求 
变化 又 是 不 可 预料 的 。 我 们 要 为 不 可 预料 的 事情 做 好 准备 ， 这 本 身 就 
是 一 件 非常 痛苦 的 事情 ， 但 是 大 师 们 还 是 给 我 们 提出 了 非常 好 的 6 大 设 
计 原则 以 及 23 个 设计 模式 来 "封装 "未 来 的 变化 ， 我 们 在 前 5 章 中 讲 过 如 
下 设计 原则 。 


e Single Responsibility Principle: 单一 职责 原则 
e Open Closed Principle: 开 闭 原则 

e Liskov Substitution Principle: 里 氏 替 换 原 则 

e Law of Demeter: 迪 米 特 法 则 

e Interface Segregation Principle: 接口 隔离 原则 
e Dependence Inversion Principle: 依赖 倒置 原则 


把 这 6 个 原则 的 首 字 母 (里 氏 莅 换 原 则 和 过 米 特 法 则 的 首 字 母 重 
复 ， 只 取 一 个 ) 联合 起 来 就 是 SOLID (solid， 稳 定 的 ) ， 其 代表 的 含 
义 也 融 是 把 这 6 个 原则 结合 使 用 的 好 处 : 建立 稳定 、 有 灵活 、 健 壮 的 设 


计 ， 而 开 闭 原则 又 是 重 中 之 重 ， 有 是 最 基础 的 原则 ， 十 其 他 5 大 原则 的 精 
神 领袖 。 我 们 在 使 用 开 闭 原则 时 要 注意 以 下 几 个 问题 。 


e 开 闭 原则 也 只 是 一 个 原则 


开 闭 原则 只 是 精神 口号 ， 实 现 拥抱 变化 的 方法 非常 多 ， 并 不 局 限 
于 这 6 大 设计 原则 ， 但 是 遵循 这 6 大 设计 原则 基本 上 可 以 应 对 大 多 数 变 
化 。 因 此 ， 我 们 在 项 目 中 应 尽量 采用 这 6 大 原则 ， 适 当时 候 可 以 进行 扩 
充 ， 例 如 通过 类 文件 蔡 换 的 方式 完全 可 以 解决 系统 中 的 一 些 缺 聊 。 大 
家 在 开发 中 比较 种 用 的 修复 缺陷 的 方法 就 是 类 替换 ， 比 如 一 个 软件 产 
品 已 经 在 运行 中 ， 发 现 了 一 个 缺 隐 ， 需 要 修正 拒 么 办 ? 如 果 有 目 动 更 
新 功能 ， 则 可 以 下 载 一 个 .class 文 件 直 接 履 新 原 有 的 class， 重 靳 局 动 应 
用 (也 不 一 定 非 要 重新 启动 ， 就 可 以 解决 问题 ， 也 就 是 通过 类 文件 的 
替换 方式 修正 了 一 个 缺 隐 ， 当 然 这 种 方式 也 可 以 应 用 到 项 目 中 ， 正 在 
运行 中 的 项 目 发 现 需要 增加 一 个 新 功能 ， 通 过 修改 原 有 实现 类 的 方式 
就 可 以 解决 这 个 问题 ， 前 提 条 件 是 : 类 必须 做 到 高 内 聚 、 低 耦合 ， 否 
则 类 文件 的 蔡 换 会 引起 不 可 预料 的 故障 。 


e 项 目 规章 非常 重要 


如 琳 你 古 一 位 项 目 经 理 或 染 构 师 ， 应 尽量 让 目 己 的 项 目 成 员 稳 
定 ， 稳 定 后 才能 建立 高 效 的 团队 文化 ， 章 程 是 一 个 团队 所 有 成 员 共 同 
的 知识 结晶 ， 也 和 是 所 有 成 员 必 须 遵守 的 约定 。 优 秀 的 章程 能 囊 给 项 目 


市 来 非常 多 的 好 处 ， 如 提高 开发 效率 、 降 低 缺 陷 率 、 提 高 团队 士气 、 


提高 技术 成 员 水 平 ， 等 等 。 


e 预知 变化 


在 实践 中 过 程 中 ， 染 构 师 或 项 目 经 理 一 旦 发 现 有 发 生变 化 的 可 
能 ， 或 者 变化 曾经 发 生 过 ， 则 需要 考虑 现 有 的 架构 是 否 可 以 轻松 地 实 
锦 这 一 变化 。 架 构 师 设计 一 套 系 统 不 仅 要 符合 现 有 的 需求 ， 还 要 适应 
能 发 生 的 变化 ， 这 才 是 一 个 优 民 的 架构 。 


可 党 


开 闭 原则 是 一 个 终极 目标 ， 任 何人 包括 大 师 级 人 物 都 无 法 百 分 之 
百 做 到 ， 但 对 这 个 方 同 努力 ， 可 以 非常 显著 地 改善 一 个 系统 的 以 构 ， 
真正 做 到 “拥抱 变化 ”。 
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第 7 章 ” 单 例 模式 


7.1 我 是 呈 帝 我 独 百 


目 从 秦 始 呈 确立 了 旦 第 这个 位 置 以 后 ， 同 一 时 期 基本 上 束 只 有 一 
个 人 孤零零 地 坐 在 这 个 位 置 。 这 种 情况 下 臣民 们 也 好 处 理 ， 大 家 久 
苦 、 谈 论 的 时 候 只 要 提 及 旦 第 ， 每 个 人 都 知道 指 的 是 谁 ， 而 不 用 在 呈 
帝 前 面 加 上 特定 的 称呼 ， 如 张 星 帝 、 李 旺 帝 。 这 一 个 过 程 反 应 到 设计 
领域 就 是 ， 要 求 一 个 类 只 能 生成 一 个 对 象 〈《 旦 帝 ) ， 所 有 对 象 对 它 的 
依赖 都 是 相同 的 ， 因 为 只 有 一 个 对 象 ， 大 家 对 它 的 脾气 和 习性 都 非常 
了 解 ， 建 立 健壮 稳固 的 关系， 我 们 把 呈 带 这 种 特殊 职业 通过 程序 来 实 
现 。 


星 帝 每 天 要 上 朝 接待 臣子 、 处 理 政务 ， 臣 和子 每 天 要 即 拜 星 帝 ， 呈 
帝 只 能 有 一 个 ， 也 就 是 一 个 类 只 能 产生 一 个 对 象 ， 该 怎么 实现 呢 ? 对 
象 产 生 是 通过 new 关 键 字 完成 的 (当然 也 有 其 他 方式 ， 比 如 对 和 象 复 
制 、 反 射 等 ) ， 这 个 怎么 控制 呀 ， 但 是 大 家 别 起 记 了 构造 画 数 ， 使 用 
new 天 键 字 创建 对 象 时 ， 都 会 根据 输入 的 参数 调用 相应 的 构造 画 数 ， 
如 果 我 们 把 构造 画 数 设置 为 private 私 有 访问 权限 不 束 可 以 至 止 外 部 创 
建 对 象 了 吗 ? 臣子 用 拜 唯一 旦 帝 的 过 程 类 几 如 图 7-1 所 示 。 


| 
-Emperor() 

+static Emperor getInstance() 

t+static void say() 


图 7-1 臣子 乃 拜 星 帝 类 图 


只 有 两 个 类 ，Emperor 代 表 星 帝 类 ，Minister 代 表 臣 子 类 ， 关 联 到 
皇帝 类 非常 简单 。Emperor 如 代码 清单 7-1 所 示 。 


代码 清单 7-1 皇帝 类 


public class Emperor { 
private static final Emperor emperor =new Emperor(); // 初 

始 化 一 个 旺 帝 
private Emperor(){ 

// 世 俗 和 道德 约束 你 ， 目 的 就 是 不 希望 产生 第 二 个 皇帝 


由 


public static Emperor getInstance(){ 
return emperor,; 


4 
// 量 帝 发 话 了 
public static void say(){ 


} 


vph 日 


通过 定义 一 个 私有 访问 权限 的 构造 画 数 ， 避 人 免 被 其 他 类 new 出 来 
一 个 对 象 ， 而 Emperor 自 己 则 可 以 new 一 个 对 象 出 来 ， 其 他 类 对 该 类 的 


访问 都 可 以 通过 getInstance 获 得 同一 个 对 象 。 
星 帝 有 了 了， 臣子 要 出 场 ， 其 类 如 代码 清单 7-2 所 示 。 


代码 清单 7-2 臣子 类 


public class Minister { 
public static void main(String[|] args) { 
for(int day=0;day<3;day++){ 
Emperor emperor=Emperor.getIinstance(); 
emperor ,Say() ， 


hl 
// 三 天 见 的 旦 帝都 是 同一 个 人 ， 采 幸 吧 ! 


臣子 参拜 旦 帝 的 运行 结果 如 下 所 示 。 


我 融 是 旺 帝 某 某 某 … 


我 就 是 皇帝 某 某 某 .…. 


我 就 是 星 帝 某 某 菜 …. 

臣子 天 天 要 上 朝 参 见 明帝， 今天 参拜 的 呈 帝 应 该 和 昨天 、 前 天 的 
一 样 “过 渡 期 的 不 考虑 ， 别 找茬 哦 ) ， 大 臣 确 完 头 ， 抬 头 一 看 ， 哮 ， 
还 古 昨 天 那个 旦 帝 ， 老 熟人 了 ， 容 易 讲话 ， 这 整 是 单 例 模式 。 


7.2 单 例 模式 的 定义 


单 例 模式 (Singleton Pattern ) 


征 一 个 比较 简单 的 模式 ， 义 如 
下 : 


Ensure a class has only one instance, and provide a global point of 
access to it. (确保 某 一 个 类 只 有 一 个 实例 ， 而 且 自 行 实 例 化 并 向 整个 系 
统 提供 这 个 实例 。) 


单 例 模式 的 通用 类 图 如 图 7-2 所 示 。 


| bk | 
| | 
[| 


-static final Singleton singleton = new Singleton() 
-Singleton() 


+static Singleton getSngleton() 


x 、 . eR 和 ~ 
通过 Singleton.getSingleton() 方 式 访问 


图 7-2 单 例 模式 通用 类 图 


Singleton 类 称 为 单 例 类 ， 通 过 使 用 private 的 构造 印 数 确保 了 在 一 个 
应 用 中 只 产生 一 个 实例 ， 并 且 是 自行 实例 化 的 (在 Singleton 中 自己 使 用 
new Singleton()) 。 单 例 模式 的 通用 源 代 码 如 代码 清单 7-3 所 示 。 


代码 清单 7-3 单 例 模式 通用 代码 


public class Singleton { 
private static final Singleton singleton = new Singleton(); 
// 限 制 产 生 多 个 对 象 
private Singleton(){ 


} 

// 通 过 该 方法 获得 实例 对 象 

public static Singleton getSingleton(){ 
return singleton; 


} 

// 类 中 其 他 方法 ， 尽 量 是 static 

public static void doSomething(){ 
} 


7.3 单 例 模式 的 应 用 


7.3.1 单 例 模 式 的 优点 


e 由 于 单 例 模 式 在 内 存 中 只 有 一 个 实例 ， 减 少 了 内 存 开 文 ， 特 别 
是 一 个 对 象 需要 频繁 地 创建 、 销 毁 时 ， 而 且 创 建 或 销毁 时 性 能 又 无 法 
优化 ， 单 例 模 式 的 优势 束 非 第 明显 。 


e 由 于 单 例 模 式 只 生成 一 个 实例 ， 所 以 减少 了 系统 的 性 能 开销 ， 
当 一 个 对 象 的 产生 需要 比较 多 的 资源 时 ， 如 读 取 配置 、 产 生 其 他 依赖 
对 象 时 ， 则 可 以 通过 在 应 用 启动 时 直接 产生 一 个 单 例 对 象 ， 然 后 用 永 
久 驻 留 内 存 的 方式 来 解决 (在 Java EE 中 采用 单 例 模式 时 需要 注意 JVM 
垃圾 回收 机 制 ) 。 


e 单 例 模 式 可 以 避免 对 资源 的 多 重 占 用 ， 例 如 一 个 写 文件 动作 ， 
由 于 只 有 一 个 实例 存在 内 存 中 ， 避 免 对 同一 个 资源 文件 的 同时 写 操 
作 。 


e 单 例 模 式 可 以 在 系统 设置 全 局 的 访问 点 ， 优 化 和 共生 资源 访 
问 ， 例 如 可 以 设计 一 个 单 例 类 ， 负 责 所 有 数据 表 的 映射 处 理 。 


7.3.2 单 例 模 式 的 缺点 


e 单 例 模式 一 般 没有 接口 ， 扩 展 很 困难 ， 奉 要 扩展 ， 除 了 修改 代 
码 基 本 上 没有 第 二 种 途径 可 以 实现 。 单 例 模 式 为 什么 不 能 增加 接口 
呢 ? 因 为 接口 对 单 例 模 式 是 没有 任何 意义 的 ， 它 要 求 “ 目 行 实例 化 ”， 
并 且 提 供 单 一 实例 、 接 口 或 抽象 类 十 不 可 能 被 实 例 化 的 。 当 然 ， 在 特 
殊 情况 下 ， 单 例 模式 可 以 实现 接口 、 被 继承 等 ， 需 要 在 系统 开发 中 根 
据 环 境 判 断 。 


。 单 例 模式 对 测试 是 不 利 的 。 在 并 行 开发 环境 中 ， 如 果 单 例 模 式 
没有 完成 ， 是 不 能 进行 测试 的 ， 没 有 接口 也 不 能 使 用 mock 的 方式 虚拟 
一 个 对 象 。 


e 单 例 模式 与 单一 职 贡 原则 有 冲突 。 一 个 类 应 该 只 实现 一 个 逻 
辑 ， 而 不 关心 它 是 否 羡 单 例 的 ， 征 不 是 要 单 例 取 决 于 环境 ， 单 例 模式 
把 “要 单 例 ” 和 业务 逻辑 融合 在 一 个 类 中 。 


7.3.3 单 例 模 式 的 使 用 场景 


在 一 个 系统 中 ， 要 求 一 个 类 有 且 仅 有 一 个 对 象 ， 如 有 果 出 现 多 个 对 
象 束 会 出 现 “ 不 民 反 应 ”可 以 采用 单 例 模 式 ， 具 体 的 场景 如 下 : 


e 要 求生 成 唯一 序列 号 的 环境 ; 


e 在 整个 项 目 中 需要 一 个 共 译 访问 点 或 共 译 数据 ， 例 如 一 个 Web 
页 面 上 的 计数 右 ， 可 以 不 用 把 每 次 刷新 都 记录 到 数据 库 中 ， 使 用 单 例 
模式 保持 计数 器 的 值 ， 并 确保 是 线程 安全 的 ; 


e 创建 一 个 对 象 需要 请 耗 的 资源 过 多 ， 如 要 访问 IO 和 数据 库 等 资 
着 ; 


e 需要 定义 大 量 的 静态 常量 和 静态 方法 (如 工具 类 ) 的 环境 ， 可 
以 采用 单 例 模 式 (当然 ， 也 可 以 直接 声明 为 static 的 方式 ) 


7.3.4 单 例 模式 的 注意 事项 


首先 ， 在 高 并 发 情况 下 ， 请 注意 单 例 模 式 的 线程 同步 问题 。 单 例 
模式 有 几 种 不 同 的 实现 方式 ， 上 面 的 例子 不 会 出 现 产生 多 个 实例 的 情 
况 ， 但 是 如 代码 清单 7-4 所 示 的 单 例 模 式 束 需要 考虑 线程 同步 。 


代码 清单 7-4 线程 不 安全 的 单 例 


public class Singleton 
private static Singleton singleton = null; 
// 限 制 产 生 多 个 对 象 
private Singleton(){ 


} 
// 通 过 该 方法 获得 实例 对 象 
public static Singleton getSingleton( ){ 
if(singleton == null)t{ 
singleton = new Singleton( ) ; 


return singleton; 


该 单 例 模式 在 低 并 发 的 情况 下 尚 不 会 出 现 问题 ， 寿 系统 压力 增 
大 ， 并 发 量 增加 时 则 可 能 在 内 存 中 出 现 多 个 实例 ， 破 坏 了 最 初 的 预 
期 。 为 什么 会 出 现 这 种 情况 呢 ? 如 一 个 线程 A 执 行 到 singleton = new 
Singleton0， 但 还 没有 获得 对 象 对象 初始 化 是 需要 时 间 的 ) ， 第 二 个 
线程 B 也 在 执行 ， 执 行 到 (singleton == null) 判断 ， 那 么 线程 B 获 得 判 
断 条 件 也 是 为 真 ， 于 是 继续 运行 下 去 ， 线 程 A 获 得 了 一 个 对 象 ， 线 程 B 
也 获得 了 一 个 对 象 ， 在 内 存 中 束 出 现 两 个 对 象 ! 


解决 线程 不 安全 的 方法 有 很 多 ， 可 以 在 getSingleton 方 法 前 加 
synchronized 关 键 字 ， 也 可 以 在 getSingleton 方 法 内 增加 synchronized 来 
实现 ， 但 都 不 是 最 优秀 的 单 例 模 式 ， 建 议 读者 使 用 如 代码 清单 7-3 所 示 
的 方式 (有 的 书 上 把 代码 清单 7-3 中 的 单 例 称 为 俄 汉 式 单 例 ， 在 代码 清 
单 7-4 中 增加 了 synchronized 的 单 例 称 为 懒汉 式 单 例 ) 。 


其 次 ， 需 要 考虑 对 象 的 复制 情况 。 在 Java 中 ， 对 象 默 认 是 不 可 以 
被 复制 的 ， 若 实现 了 Cloneable 接 口 ， 并 实现 了 clone 方 法 ， 则 可 以 直接 
通过 对 象 复 制 方式 创建 一 个 新 对 象 ， 对 和 象 复制 是 不 用 调用 类 的 构造 画 
数 ， 因 此 即使 是 私有 的 构造 丁 数 ， 对 象 仍然 可 以 被 复制 。 在 一 般 情 况 
下 ， 类 复制 的 情况 不 需要 考虑 ， 很 少 会 出 现 一 个 单 例 类 会 主动 要 求 被 
复制 的 情况 ， 解 决 该 问题 的 最 好 方法 就 古 单 例 类 不 要 实现 Cloneable 接 
站 二 


7.4 单 例 模 式 的 扩展 


如 采 一 个 类 可 以 产生 多 个 对 象 ， 对 和 象 的 数量 不 受 限 制 ， 则 是 非常 容易 
实现 的 ， 直 接 使 用 new 关 键 子 束 可 以 了 ， 如 采 只 需要 一 个 对 象 ， 使 用 单 例 
模式 束 可 以 了 ， 但 是 如 果 要 求 一 个 类 只 能 产生 两 三 个 对 象 呢 ? 该 怎么 实 
现 ? 我 们 还 以 呈 帝 为 例 来 说 明 。 


一 般 情 况 下 ， 一 个 朝代 的 同一 个 时 代 只 有 一 个 旺 帝 ， 那 有 没有 出 现 两 
个 旺 帝 的 情况 呢 ? 确实 有 ， 束 出 现在 明 朝 ， 那 三 国 期 间 的 算 不 算 ? 不 算 ， 
各 目 称 帝 ， 各 有 各 的 地 强 ， 国 号 不 同 。 大 家 还 记得 《石灰 吟 》 这 首 诗 吗 ? 
作者 是 谁 ? 于 谦 。 他 是 被 谁 杀 死 的 ? 明 英 宗 朱 祁 镇 。 对 ， 束 是 那个 在 土木 
堡 之 变 中 被 瓦 刺 俘虏 的 星 帝 ， 被 俘虏 后 ， 他 弟 第 朱 祁 钰 当 上 了 旦 帝 ， 束 旦 
明 景 芝 ， 估 计 刚 当 上 旺 帝 乐 疾 了 ， 环 记 把 他 哥哥 朱 祁 镇 升级 为 太 上 旺 ， 在 
那个 时 期 下 出 现 了 两 个 旦 帝 ， 这 期 间 的 大 臣 是 非常 郁 问 的 ， 为 什么 呀 ? 因 
为 可 能 出 现今 天 参拜 的 旺 帝 和 昨天 的 旦 带 不 相同 ， 昨 天 给 那个 旺 帝 汇 报 ， 
今天 还 要 给 这 个 旺 帝 汇报 一 般 ， 该 情况 的 类 图 如 图 7-3 所 示 。 


+static int maxNumOfEmperor = 


-Emperor() 

-Emperor(Strng name) 
+static Emperor getInstance() 
+static vold say() 


maxNumOfEmperor 最 大 的 呈 贡 数 : 


图 7-3 多 个 旺 帝 类 图 


这 个 类 图 看 起 来 还 算 简单 ， 但 是 实现 就 有 点 复杂 了 。Emperor 类 如 代 
码 清单 7-5 所 示 。 


代码 清单 7-5 固定 数量 的 旺 帝 类 


public class Emperor { 
// 定 义 最 多 能 产生 的 实例 数量 
private static int maxNumofEmperor = 2; 
// 每 个 皇帝 都 有 名 字 ， 使 用 一 个 ArrayList 来 容纳 ， 每 个 对 象 的 私有 属 怡 
private static ArrayList<String> nameList=new 
ArrayList<String>( ); 
// 定 义 一 个 列表 ， 容 纳 所 有 的 皇帝 实例 
private static ArrayList<Emperor> emperorList=new 
ArrayList<Emperor>(); 
// 当 前 旦 帝 序 列 号 
private static int countNumofEmperor =0; 
// 产 生 所 有 的 对 象 
static{ 
for(int i=0;i<maxNumOfEmperor;i++){ 
emperorList.add(new Emperor(" 皇 "+(i+1)+" 帝 ") ) 
} 


private Emperor()t{ 
// 世 俗 和 道德 约束 你 ， 目 的 就 是 不 产生 第 二 个 皇帝 
} 


TT 


// 传 入 旦 帝 名 称 ， 建 立 一 个 旦 帝 对 象 
private Emperor(String name)t{ 
nameList.add(name); 


} 

// 随 机 获得 一 个 皇帝 对 象 

public static Emperor getInstance(){ 
Random random = new Random( ); 
// 随 机 拉 出 一 个 星 帝 ， 只 要 是 个 精神 领袖 就 成 
countNumoOofEmperor = random.nextInt(maxNumofEmperor ) ; 
return emperorList ,get(countNumOfEmperor ) ; 


} 

// 旦 帝 发 话 了 

public static void say()t{ 
System.out.println(nameList.get(countNumOfEmperor)); 

} 


在 Emperor 中 使 用 了 两 个 ArrayList 分 别 存储 实例 和 实例 变量 。 当 然 ， 
如 果 考 虑 到 线程 安全 问题 可 以 使 用 Vector 来 代替 。 臣 子 参拜 星 帝 的 过 程 如 
代码 清单 7-6 所 示 。 


代码 清单 7-6 臣子 参拜 星 帝 的 过 程 


public class Minister { 
public static void main(String[] args) { 

// 定 义 5 个 大 臣 

int ministerNum =5， 

for(int i=0;i<ministerNum;i++){ 
Emperor emperor = Emperor.getInstance()， 
System.out .print(" 第 "+(Ii+1)+" 个 大 臣 参 拜 的 是 : ") ; 
emperor .Say() ; 


大 臣 参 拜 星 带 的 结果 如 下 所 示 。 


第 1 个 大 臣 参 拜 的 是 : 星 1 帝 


第 2 个 大 臣 参 拜 的 是 : 星 2 


亏 


第 3 个 大 臣 参 拜 的 是 : 星 1 


< 


< 


第 4 个 大 臣 参 拜 的 是 : 星 1 


第 5 个 大 臣 参拜 的 


星 2 第 


(ou 


看 ， 采 然 每 个 大 臣 参 拜 的 旦 帝都 可 能 不 一 样 ， 大 臣 们 吏 开 始 糊涂 了 ， 
A 大 臣 给 皇 1 帝 汇报 了 一 件 事 情 ， 皇 2 帝 不 知道 ， 然 后 就 开始 怀疑 大 臣 A 是 
旦 1 帝 的 亲信 ， 人 然后 吏 想 办 法 开始 整 


这 种 需要 产生 固定 数量 对 象 的 模式 就 叫做 有 上 限 的 多 例 模式 ， 它 十 
例 模 式 的 一 种 扩展 ， 采 用 有 上 限 的 多 例 模式 ， 我 们 可 以 在 设计 时 决定 在 内 
存 中 有 多 少 个 实例 ， 方 便 系 统 进行 扩展 ， 修 正 单 例 可 能 存在 的 性 能 问题 ， 
提供 系统 的 啊 应 速度 。 例 如 读 取 文件 ， 我 们 可 以 在 系统 局 动 时 完成 初始 化 
工作 ， 在 内 存 中 启动 固定 数量 的 reader 实 例 ， 然 后 在 需要 读 取 文件 时 就 可 
以 快速 响应 。 


7.5 最 佳 实践 


单 例 模式 是 23 个 模式 中 比较 简单 的 模式 ， 应 用 也 非常 广泛 ， 如 在 
Spring 中 ， 每 个 Bean 默 认 就 是 单 例 的 ， 这 样 做 的 优点 是 Spring 容器 可 以 
管理 这 些 Bean 的 生命 期 ， 决 定 什么 时 候 创建 出 来 ， 什 么 时 候 销毁 ， 销 
毁 的 时 候 要 如 何 处 理 ， 等 等 。 如 果 采 用 非 单 例 模式 (Prototype 类 
型 ) ， 则 Bean 初 始 化 后 的 管理 交 由 J2EE 容 器 ，Spring 容 器 不 再 跟踪 管 
理 Bean 的 生命 周期 。 


第 8 章 ” 工 上 方法 模式 


8.1 女 娲 扶 人 的 故事 


东汉 《风俗 通 》 记 录 了 一 则 神话 故事 :“ 开 天 尽 地 ， 未 有 人 民 ， 女 
娲 搏 黄土 做 人 ”， 讲 述 的 内 容 束 是 大 家 非常 熟悉 的 女 姻 造 人 的 故事 。 开 
天 辟 邯 之 初 ， 大 地 上 并 没有 生物 ， 只 有 个 范 大 地 ， 纯 粹 而 活 净 的 目 然 
环境 ， 疲 静 而 又 寂寞 ， 于 是 女 娲 决定 创造 一 个 新 物种 ( 即 人 类 ) 来 增 
加 世界 的 索 采 ， 怎 么 制造 呢 ? 


别 起 了 女 娲 古 神 仙 ， 没 有 办 不 到 的 事情 ， 造 人 的 过 程 是 这 样 的 : 
首 爷 ， 女 娲 采集 黄土 捏 成 人 的 形状 ， 然 后 放 到 八卦 炉 中 烧 制 ， 最 后 放 
置 到 大 地 上 生长 ， 工 艺 过程 是 没有 错 的 ， 但 是 意外 随时 都 会 发 生 : 


第 一 次 烤 泥人 ， 感 觉 应 该 熟 了 ， 往 大 地 上 一 放 ， 哇 ， 没 烤 熟 ! 于 
是 一 个 白人 诞生 了 ! (这 也 是 缺乏 经 验 的 最 好 证 明 。) 

第 二 次 烤 泥 人 ， 上 一 次 没 烤 熟 ， 这 次 多 烤 一 会 儿 ， 放 到 世间 一 
看 ， 嘿 ， 熟 过 头 了 ， 于 是 黑人 诞生 了 | 


第 三 次 烤 泥 人 ， 一 边 烧 制 一 边 察 看 ， 直 到 表皮 微 芮 ， 吗 ， 刚 刚 
好 ， 于 是 


这 个 造 人 过 程 是 比较 有 意思 的 ， 征 不 是 可 以 通过 软件 开发 来 实现 
这 个 过 程 呢 ? 古人 云 :“ 三 人 行 ， 必 有 我 师 看 ”， 在 面 问 对 象 的 思维 
中 ， 万 物 缘 对 象 ， 征 对 象 我 们 就 可 以 通过 软件 设计 来 实现 。 首 先 对 造 
人 过 程 进 行 分 析 ， 该 过 程 涉及 三 个 对 象 : 女 娲 、 八 卦 护 、 三 种 不 同 肤 
色 的 人 。 女 娲 可 以 使 用 场景 类 Client 来 表示 ， 八 卦 炉 类 似 于 一 个 工厂 ， 
负责 制造 生产 产品 〈 即 人 类 ) ， 三 种 不 同 肤色 的 人 ， 他 们 都 是 同一 个 
接口 下 的 不 同 实现 类 ， 都 症 人 嘛 ， 只 旦 肤色 、 语 言 不 同 ， 对 于 八卦 护 
来 说 都 是 它 生 产 出 的 产品 。 分 析 完 毕 ， 我 们 束 可 以 画 出 如 图 8-1 所 示 的 
类 图 。 


类 图 比较 简单 ，AbstractHumanFactory 是 一 个 抽象 类 ， 定 义 了 一 个 
八卦 炉 具 有 的 整体 功能 ，HumanFactory 为 实现 类 ， 完 成 具体 的 任务 
一 一 创建 人 类 ; Human 接 口 是 人 类 的 总 称 ， 其 三 个 实现 类 分 别 为 三 类 
人 种 ;NvWa 类 是 一 个 场景 类 ， 负 责 模拟 这 个 场景 ,执行 相关 的 任务 。 


我 们 定义 的 每 个 人 种 都 有 两 个 方法 : getColor (获得 人 的 皮肤 颜 
色 ) 和 talk (交谈 ) ， 其 源 代码 如 代码 清单 8-1 所 示 。 


z 
< 
三 
二 


<<interface>> 
AbstractHumanF actory i 


| -| 
+Human createHuman(Class c) +Void getColorOf™ 
: Hvoid talk() 


人 


> 


YellowHuman WhiteHuman 
ER 
[| ”| 


抽象 的 八卦 炉 


| | 
| | 


黑色 人 种 | 黄色 人 种 】 [白色 人 种 


图 8-1 女 娲 造 人 类 图 


代码 清单 8-1 人 类 总 称 


public interface Human { 
// 每 个 人 种 的 皮肤 都 有 相应 的 颜色 
public void getColor(); 
// 人 类 会 说 话 
public void talk(); 


接口 Human 是 对 人 类 的 总 称 ， 每 个 人 种 都 至 少 具 有 两 个 方法 ， 


色 人 种 、 黄 色 人 种 、 自 色 人 种 的 代码 分 别 如 代码 清单 8-2、 代 码 清单 8- 
3、 代 码 清 单 8-4 所 示 。 
代码 清单 8-2 黑色 人 种 


public class BlackHuman implements Human { 
public void getColor()t{ 
System,.,out.println(" 黑 色 人 种 的 皮肤 颜色 是 黑色 的 !")， 


} 
public void talk() { 

System.out.println(" 黑 人 会 说 话 ， 一 般 人 听 不 懂 。" ); 
} 


旺 


代码 清单 8-3 黄色 人 种 


public class YellowHuman implements Human { 
public void getColor()t{ 
System.out.println(" 黄 色 人 种 的 皮肤 颜色 是 黄色 的 !")， 


} 
public void talk() { 
System.out.println(" 黄 色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 


代码 清单 8-4 日 色 人 种 


public class WhiteHuman implements Human { 
public void getColor(){ 
System.out .println(" 日 色 人 种 的 皮肤 颜色 是 日 色 的 !"); 


} 
public void talk() { 
System.out.println(" 白 色 人 种 会 说 话 ， 一 般 都 是 但 是 单字 


所 有 的 人 种 定义 完毕 ， 下 一 步 就 是 定义 一 个 八卦 加， 然后 烧 制 人 
类 。 我 们 想象 一 下 ， 女 娲 最 可 能 给 八卦 加 下 达 什 么 样 的 生产 命令 呢 ? 
应 该 是 “给 我 生产 出 一 个 黄色 人 种 (YellowHuman 类 ) ”， 而 不 会 是 “给 
我 生产 一 个 会 走 、 会 跑 、 会 说 话 、 皮 肤 是 黄色 的 人 种 ”， 因 为 这 样 的 命 
令 增加 了 交流 的 成 本 ， 作 为 一 个 生产 的 管理 者 ， 只 要 知道 生产 什么 融 
可 以 了 ， 而 不 需要 事物 的 具体 信息 。 通 过 分 析 ， 我 们 发 现 八 卦 炉 生 产 


人 类 的 方法 输入 参数 类 型 应 该 是 Human 接 口 的 实现 类 ， 这 也 解释 了 为 
什么 类 图 上 的 AbstractHumanFactory 抽 象 类 中 createHuman 方 法 的 参数 为 
Class 关 型 。 其 源 代 码 如 代码 清单 8-5 所 示 。 


代码 清单 8-5 抽象 人 类 创建 工厂 


public abstract class AbstractHumanFactory { 
public abstract <T extends Human> T createHuman(Class<T> 
c); 


} 
注意 ， 我 们 在 这 里 采用 了 泛 型 (Generic) ， 通 过 定义 泛 型 对 
createHuman 的 输入 参数 产生 两 层 限 制 ; 


e 必须 是 Class 类 型 ; 


e@ 必须 是 Human 的 实现 类 。 


其 中 的 "T" 表 示 的 是 ， 只 要 实现 了 Human 接 口 的 类 都 可 以 作为 参 
数 ， 泛 型 是 JDK 1.5 中 的 一 个 非常 重要 的 者 特性 ， 它 减少 了 对 象 间 的 转 
换 ， 约 束 其 输入 参数 类 型 ， 对 Collection 集 合 下 的 实现 类 都 可 以 定义 泛 
型 。 有 关 泛 型 的 详细 知识 ， 请 参考 相关 的 Java 语 法 文档 。 


目前 女 娲 只 有 一 个 八卦 炉 ， 其 实现 生产 人 类 的 方法 ， 如 代码 清单 8- 
6 所 示 。 


代码 清单 8-6 人 类 创建 工厂 


public class HumanFactory extends AbstractHumanFactory { 
public <T extends Human> T createHuman(Class<T> C){ 
// 定 义 一 个 生产 的 人 种 
Human human=null; 
try { 


// 产 生 一 个 人 种 
human = 
(T)Class.forName(c.getName()).newInstance( ); 
} catch (Exception e) { 
System.out.printLn(" 人 种 生成 错误 ! ") ， 


return (T)human; 


证 


人 种 有 了 ， 八 卦 炉 也 有 了 ， 和 独 下 的 工作 束 是 女 娲 采集 黄土 ， 然 后 
命令 八卦 炉 开 始 生产 ， 其 过 程 如 代码 清单 8-7 所 示 。 


代码 清单 8-7 女 娲 类 


public class NVWa { 
public static void main(String[] args) { 
// 声 明 阴 阳 八 卦 炉 
AbstractHumanFactory YinYangLu = new 
HumanFactory( ); 
// 女 娲 第 一 次 造 人 ， 火 候 不 足 ， 于 是 白人 产生 1 
System.out .println("-- 造 出 的 第 一 批 人 是 白色 人 种 --"); 
Human whiteHuman = 
YinYangLu.createHuman(WhiteHuman.class); 
whiteHuman.getColor(); 
whiteHuman.talk( ); 
// 女 姻 第 二 次 造 人 ， 火 候 过 足 ， 于 是 黑人 产生 
System.out.println("\n-- 造 出 的 第 二 批 人 是 黑色 人 种 - -"); 
Human blackHuman = 
YinYangLu.createHuman(BlackHuman.class); 
blackHuman.getColor(); 
blackHuman. talk( ); 
// 第 三 次 造 人 ， 火 候 刚 刚好 ， 于 是 黄色 人 种 产生 了 
System.out ， D710tIn (他 由 的 第 三 批 人 是 黄色 人 种 - -")， 
Human yellowHuman = 
YinYangLu.createHuman(YellowHuman.class); 
yellowHuman.getColor(); 
yellowHuman. talk( ); 


人 种 有 了 ， 八 卦 加 有 了 ， 人 负责 生产 的 女 娲 也 有 了 ， 激 动人 心 的 时 
刻 到 来 了 ， 我 们 运行 一 下 ， 结 果 如 下 所 示 。 


-- 造 出 的 第 一 批 人 是 白色 人 种 -- 

日 色 人 种 的 皮肤 颜色 是 白色 的 ! 

白色 人 种 会 说 话 ， 一 般 都 是 单字 节 。 
-- 造 出 的 第 二 批 人 是 黑色 人 种 -- 

黑色 人 种 的 庆 肤 颜色 下 黑色 的 ! 

黑人 会 说 话 ， 一 般 人 听 不 懂 。 

-- 造 出 的 第 三 批 人 是 黄色 人 种 -- 

黄色 人 种 的 皮肤 颜色 是 黄色 的 ! 

黄色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 节 。 


哇 ， 人 类 的 生产 过 程 束 展现 出 来 了 ! 这 个 世界 束 热 闸 起 来 了 ， 黑 
人 、 白 人 、 黄 人 部 开 始 活 动 了 ， 这 也 正 古 我 们 现在 的 真实 世界 。 以 上 
就 是 工厂 方法 模式 ( 没 错 ， 对 该 部 分 有 疑问 ， 请 继续 阅读 下 去 ) 。 


8.2 工厂 方法 模式 的 定义 


工厂 方法 模式 使 用 的 频率 非 第 高， 在 我 们 日 常 的 开发 中 总 能 见 到 


它 的 身影 。 其 定义 为 : 


Define an interface for creating an object,but let subclasses decide 


which class to instantiate.Factory Method lets a class defer instantiation to 


subclasses，( 定 义 一 个 用 于 创建 对 象 的 接口 ， 让 子 类 决定 实例 化 哪 一 个 


类 。 工 三 方法 使 一 个 类 的 实例 化 延迟 到 其 子 类 。) 


工厂 方法 模式 的 通用 类 图 如 图 8-2 所 示 。 


Product 
EE | 
| 


ConcreteProduct 


RS 
图 8-2 工厂 方法 模式 通用 类 图 


在 工厂 方法 模式 中 ， 抽 象 产品 类 Product 人 负 贡 定义 产 


品 的 共性 ， 实 
共 


现 对 事物 最 抽象 的 定义 ，Creator 为 抽象 创建 类 ， 也 就 是 抽象 工矿， 


体 如 何 创 建 产品 类 是 由 具体 的 实现 工厂 ConcreteCreator 完 成 的 。 工 三 
方法 模式 的 变种 较 多 ， 我 们 来 看 一 个 比较 实用 的 通用 源码 。 


抽象 产品 类 代码 如 代码 清单 8-8 所 示 。 


代码 清单 8-8 抽象 产品 类 


public abstract class Product { 
// 产 品类 的 公共 方法 
public void method1i(){ 
// 业 务 有 逻辑 处 理 


} 
// 抽 象 方法 
public abstract void method2() ; 


具体 的 产品 类 可 以 有 多 个 ， 都 继承 于 抽象 产品 类 ， 其 源 代码 如 代 
码 清单 8-9 所 示 。 


代码 清单 8-9 具体 产品 类 


public class ConcreteProduct1 extends Product { 
public void method2() { 
// 业 务 有 逻辑 处 理 
+ 


public class ConcreteProduct2 extends Product { 
public void method2() { 
// 业 务 逻 辑 处 理 
上 


抽象 工厂 类 人 负责 定义 产品 对 象 的 产生 ， 源 代码 如 代码 清单 8-10 所 


代码 清单 8-10 抽象 工厂 类 


public abstract class Creator { 
人 
* 创建 一 个 产品 对 象 ， 其 输入 参数 类 型 可 以 自行 设置 
* 通常 为 String、Enum、Class 等 ， 当 然 也 可 以 为 空 
*/ 
public abstract <T extends Product> T 
createProduct(Class<T> c); 


} 


具体 如 何 产 生 一 个 产品 的 对 象 ， 是 由 具体 的 工厂 类 实现 的 ， 如 代 
码 清单 8-11 所 示 。 


代码 清单 8-11 具体 工厂 类 


public class ConcreteCreator extends Creator { 
public <T extends Product> T createProduct(Class<T> c)t{ 
Product product=null; 
try { 
product = 
(Product )Class.forName(c.getName()).newInstance( ); 
} catch (Exception e) { 
// 异 常 处 理 


return (T)product; 


场景 类 的 调用 方法 如 代码 清单 8-12 所 示 。 


代码 清单 8-12 场景 类 


public class Client { 
public static void main(String[] args) { 
Creator creator = new ConcreteCreator(); 
Product product = 
creator.createProduct(ConcretePproduct1.class); 
DA 


* 继续 业务 处 理 


该 通用 代码 十 一 个 比较 实用 、 易 扩展 的 框架 ， 读 者 可 以 根据 实际 
项 目 需要 进行 扩展 。 


8.3 工厂 方法 模式 的 应 用 
8.3.1 工厂 方法 模式 的 优点 


首 完 ， 民 好 的 封 小 性 ， 代 码 结构 清晰 。 一 个 对 象 创建 是 有 条 件 约 
束 的 ， 如 一 个 调用 者 需要 一 个 具体 的 产品 对 象 ， 只 要 知道 这 个 产品 的 
类 名 (或 约束 字符 串 ) 就 可 以 了 ， 不 用 知道 创建 对 象 的 艰 节 过 程 ， 降 
低 模 块 间 的 耦合 。 


其 次 ， 工 广 方法 模式 的 扩展 性 非常 优秀 。 在 增加 产品 类 的 情况 
下 ， 只 要 适当 地 修改 具体 的 工厂 类 或 扩展 一 个 工厂 类 ， 就 可 以 完成 “ 拥 
抱 变 化 *。 例如 在 我 们 的 例子 中 ， 需 要 增加 一 个 柠 色 人 种 ， 则 只 需要 增 
加 一 个 BrownHuman 类 ， 工 厂 类 不 用 任何 修改 避 ® 可 完成 系统 扩展 。 


再 次 ， 屏 蔽 产品 类 。 这 一 特点 非常 重要 ， 产 品类 的 实现 如 何 变 
化 ， 调 用 者 都 不 需要 关心 ， 它 只 需要 关心 产品 的 接口 ， 只 要 接口 保持 
不 变 ， 系 统 中 的 上 层 模块 吏 不 要 发 生变 化 。 因 为 产品 类 的 实例 化 工作 
征 由 工 广 类 负责 的 ， 一 个 产品 对 象 具 体 由 哪 一 个 产品 生成 是 由 工厂 类 
决定 的 。 在 数据 库 开 发 中 ， 大 家 应 该 能 够 深刻 体会 到 工厂 方法 模式 的 
好 处 : 如 采 使 用 JDBC 连 接 数 据 库 ， 数 据 库 从 MYSQL 切换 到 Oracle， 需 
要 改动 的 地 方 束 是 切换 一 下 驱动 名 称 〈 前 提 条 件 是 SQL 语句 是 标准 语 


句 ) ， 其 他 的 都 不 需要 修改 ， 这 是 工厂 方法 模式 灵活 性 的 一 个 直接 案 
例 。 


最 后 ， 工 厂 方法 模式 钙 典 型 的 解 耐 框架。 高层 模块 只 需要 知道 产 
品 的 抽象 类 ， 其 他 的 实现 类 都 不 用 天心， 符合 迪 米 特 法 则 ， 我 不 需要 
的 整 不 要 去 交流 ， 也 符合 依赖 倒置 原则 ， 只 依赖 产品 类 的 抽象 ， 当 人 然 
也 符合 里 氏 奉 换 原 则 ， 使 用 产品 子 类 替换 产品 父 类 ， 没 问题 ! 


8.3.2 工厂 方法 模式 的 使 用 场景 


首先 ， 工 广 方法 模式 是 new 一 个 对 象 的 奉 代 品 ， 所 以 在 所 有 需要 
生成 对 象 的 地 方 都 可 以 使 用 ， 但 是 需要 慎重 地 考虑 是 否 要 增加 一 个 工 
上 类 进行 管理 ， 增 加 代码 的 复杂 度 。 


其 次 ， 需 要 灵活 的 、 可 扩展 的 框 染 时 ， 可 以 考虑 采用 工厂 方法 模 
式 。 万 物 几 对 象 ， 那 万 物 也 束 几 产品 类 ， 例 如 需要 设计 一 个 连接 邮件 
服务 器 的 框架 ， 有 三 种 网 络 协 议 可 供 选 择 : POP3、IMAP、HTTP， 我 
们 就 可 以 把 这 三 种 连接 方法 作为 产品 类 ， 定 义 一 个 接口 如 
IConnectMail， 然 后 定义 对 邮件 的 操作 方法 ， 用 不 同 的 方法 实现 三 个 
具体 的 产品 类 (也 就 是 连接 方式 ) 再 定义 一 个 工厂 方法 ， 按 照 不 同 的 
传 入 条 件 ， 选 择 不 同 的 连接 方式 。 如 此 设计 ， 可 以 做 到 完美 的 扩展 ， 


如 某 些 邮件 服务 器 提供 了 WebService 接 口 ， 很 好 ， 我 们 只 要 增加 一 个 
产品 类 整 可 以 了 。 


再 次 ， 工 厂 方法 模式 可 以 用 在 异 构 项 目 中 ， 例 如 通过 WebService 
与 一 个 非 Java 的 项 目 交 筷 ， 虽 然 WebService 号 称 是 可 以 做 到 异 构 系统 
的 同 构 化 ， 但 是 在 实际 的 开发 中 ， 还 是 会 碰 到 很 多 问题 ， 如 类 型 问 
题 、WSDL 文 件 的 文 持 问 题 ， 等 等 。 从 WSDL 中 产生 的 对 象 都 认为 是 
一 个 产品 ， 然 后 由 一 个 具体 的 工厂 类 进行 管理 ， 减 少 与 外 围 系 统 的 类 


合 。 


最 后 ， 可 以 使 用 在 测试 驱动 开发 的 框架 下 。 例 如 ， 测 试 一 个 类 
A， 就 需要 把 与 类 A 有 关联 关系 的 类 B 也 同时 产生 出 来 ， 我 们 可 以 使 用 
工厂 方法 模式 把 类 B 虚 拟 出 来 ， 避 免 类 A 与 类 B 的 耦合 。 目 前 由 于 
JMock 和 EasyMock 的 诞生 ， 该 使 用 场景 已 经 弱化 了 ， 读 者 可 以 在 遇 到 
此 种 情况 时 直接 考虑 使 用 JMock 或 EasyMock。 


8.4 工厂 方法 模式 的 扩展 


工厂 方法 模式 有 很 多 扩展 ， 而 且 与 其 他 模式 结合 使 用 威力 更 大 ， 
下 面 将 介绍 4 种 扩展 。 


1. 缩小 为 简单 工 | 模式 


我 们 这 样 考虑 一 个 问题 : 一 个 模块 仅 需要 一 个 工厂 类 ， 没 有 必要 
把 它 产 生出 来 ， 使 用 静态 的 方法 束 可 以 了 ， 根 据 这 一 要 求 ， 我 们 把 上 
例 中 的 AbstarctHumanFactory 修 改 一 下 ， 类 图 如 图 8-3 所 示 。 


NvWa 


<<interface>> 
Human 


+static Human createHuman(Class c) 
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| | 
+void getColor() 下 人 类 | 
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黑色 人 种 黄色 人 种 自 [和 白色 人 种 他 


图 8-3 简单 工厂 模式 类 图 


我 们 在 类 图 中 去 掉 了 AbstractHumanFactory 抽 和 象 类 ， 同 时 把 
createHuman 方 法 设置 为 静态 类 型 ， 简 化 了 类 的 创建 过 程 ， 变 更 的 源码 
仅仅 是 HumanFactory 和 NvWa 类 ，HumanFactory 如 代码 清单 8-13 所 示 。 


代码 清单 8-13 简单 工厂 模式 中 的 工厂 类 


public class HumanFactory { 
public static <T extends Human> T createHuman(Class<T> c){ 
// 定 义 一 个 生产 出 的 人 种 
Human human=null; 


try { 
// 产 生 一 个 人 种 
human = 
(Human)Class.forName(c.getName()).newInstance( ); 
} catch (Exception e) { 
System.out.println(" 人 种 生成 错误 ! ")， 


return (T)human; 


HumanFactory 类 仅 有 两 个 地 方 发 生变 化 : 去 掉 继 承 抽象 类 ， 并 在 
createHuman 前 增加 static 关 键 字 ; 工厂 类 发 生变 化 ， 也 同时 引起 了 调用 
者 NvWa 的 变化 ， 如 代码 清单 8-14 示 。 


代码 清单 8-14 们 蛙 工 厂 模 式 中 的 场景 


public class NVWa { 
public static void main(String[] args) { 

// 女 姻 第 一 次 造 人 ， 火 候 不 足 ， 于 是 白色 人 种 产生 了 
System.out. println("- - 造 出 的 第 一 批 人 是 白色 人 种 - -"); 
Human whiteHuman = 

HumanFactory.createHuman(WhiteHuman.class); 
whiteHuman.getColor(); 
whiteHuman.talk( ); 
// 女 姻 第 二 次 造 人 ， 火 候 过 足 ， 于 是 黑色 人 种 产生 了 
System.out.println("\n-- 造 出 的 第 二 批 人 是 黑色 人 种 - -"); 


Human blackHuman = 
HumanFactory.createHuman(BlackHuman.class); 

blackHuman .getColor(); 

blackHuman. talk( ); 

// 第 三 次 造 人 ， 火 候 刚 刚好 ， 于 是 黄色 人 种 产生 了 

System.out .println("Nn-- 造 出 的 第 三 批 人 是 黄色 人 种 --") ; 

Human yellowHuman = 
HumanFactory.createHuman(YellowHuman.class); 

yellowHuman.getColor(); 

yellowHuman. talk( ); 


运行 结果 没有 发 生变 化 ， 但 是 我 们 的 类 图 变 人 简单 了 ， 而 且 调 用 者 
也 比较 简单 ， 该 模式 是 工厂 方 法 模式 的 弱化 ， 因 为 简单 ， 所 以 称 为 答 
单 工厂 模式 (Simple Factory Pattern) ， 也 叫做 静态 工厂 模式 。 在 实际 
项 目 中 ， 采 用 该 方法 的 案例 还 是 比较 多 的 ， 其 缺点 是 工厂 类 的 扩展 比 
较 困 难 ， 不 符合 开 闭 原则 ， 但 它 仍 然 是 一 个 非常 实用 的 设计 模式 。 


四 关 


当 我 们 在 做 一 个 比较 复杂 的 项 目 时 ， 经 常会 遇 到 初始 化 一 个 对 象 
很 耗费 精力 的 情况 ， 所 有 的 产品 类 都 放 到 一 个 工厂 方法 中 进行 初始 化 
会 使 代码 结构 不 清晰 。 例 如 ， 一 个 产品 类 有 5 个 具体 实现 ， 每 个 实现 类 
的 初始 化 (不 仅仅 是 new， 和 初始 化 包括 new 一 个 对 象 ， 并 对 对 象 设置 一 
定 的 初始 值 ) 方法 都 不 相同 ， 如 采写 在 一 个 工厂 方法 中 ， 势 必 会 导致 
该 方法 巨大 无 比 ， 那 该 怎么 办 ? 


考虑 到 需要 结构 清晰 ， 我 们 就 为 每 个 产品 定义 一 个 创造 者 ， 然 后 
由 调用 者 目 己 去 选择 与 哪个 工厂 方法 关联 。 我 们 还 古 以 女 娲 过 人 为 


例 ， 每 个 人 种 都 有 一 个 固定 的 八卦 妨 ， 分 别 造 出 黑色 人 种 、 日 色 人 
种 、 黄 色 人 种 ， 修 改 后 的 类 图 如 图 8-4 所 示 。 


<<mterface>> 
Human 


+Volid getColor() 
+vold talk() 


人 人 | 


BlackHuman YellowHuman White Human 


AbstractHumanFactory i 
+Human createHuman() 


BlackHumaFactory| | YellowHumanFactory 


村 = 二 -二 二 - 动 
创建 黑色 人 种 | 创建 黄色 人 种 】 | 创建 白色 人 种 


White HumanFactory 


图 8-4 多 个 工厂 类 的 类 图 
每 个 人 种 (具体 的 产品 类 ) 都 对 应 了 一 个 创建 者 ， 每 个 创建 者 都 
独立 负责 创建 对 应 的 产品 对 象 ， 非 常 符合 单一 职责 原则 ， 按 照 这 种 模 
式 我 们 来 看 看 代码 变化 。 


多 工厂 模式 的 抽象 工厂 类 如 代码 清单 8-15 所 示 。 


代码 清单 8-15 多 工厂 模式 的 抽象 工厂 类 


public abstract class AbstractHumanFactory { 
public abstract Human createHuman(); 


注意 ”抽象 方法 中 已 经 不 再 需要 传递 相关 参数 了 ， 因 为 每 一 个 具 
体 的 工厂 都 已 经 非常 明确 目 己 的 职责 : 创建 自己 负责 的 产品 类 对 象 。 


黑色 人 种 的 创建 工厂 如 代码 清单 8-16 所 示 。 


代码 清单 8-16 黑色 人 种 的 创建 工厂 实现 


public class BlackHumanFactory extends AbstractHumanFactory { 
public Human createHuman() { 
return new BlackHuman( ) ; 
} 


黄色 人 种 的 创建 工厂 如 代码 清单 8-17 所 示 。 


代码 清单 8-17 黄色 人 种 的 创建 类 


public class YellowHumanFactory extends AbstractHumanFactory { 
public Human createHuman() { 
return new YellowHuman(); 
} 


日 色 人 种 的 创建 工厂 如 代码 清单 8-18 所 示 。 


代码 清单 8-18 日 色 人 种 的 创建 类 


public class whiteHumanFactory extends AbstractHumanFactory { 
public Human createHuman() { 
return new WhiteHuman( ) ; 


三 个 具体 的 创建 工厂 都 非常 简单 ， 但 是 ， 如 果 一 个 系统 比较 复杂 
时 工厂 类 也 会 相应 地 变 复杂 。 场 景 类 NvWa 修 改 后 的 代码 如 代码 清单 8- 
19 所 示 。 


代码 清单 8-19 场景 类 NvWa 


public class NVWa { 
public static void main(String[] args) { 
// 女 姻 第 一 次 造 人 ， 火 候 不 足 ， 于 是 白色 人 种 产生 了 
System,out,println("-- 造 出 的 第 一 批 人 是 白色 人 种 --"); 
Human whiteHuman = (new 
WhiteHumanFactory( ) ) .createHuman( ) ; 
whiteHuman.getColor(); 
whiteHuman.talk( ); 
// 女 姻 第 二 次 造 人 ， 火 候 过 足 ， 于 是 黑色 人 种 产生 了 
System.out.println("\n-- 造 出 的 第 二 批 人 是 黑色 人 种 - -"); 
Human blackHuman = (new 
BlackHumanFactory()).createHuman(); 
blackHuman .getColor(); 
blackHuman. talk( ); 
// 第 三 次 造 人 人， 火候 刚 刚好 ， 于 是 黄色 人 种 产生 了 
System.out.println("\n-- 造 出 的 第 三 批 人 是 黄色 人 种 - -"); 
Human yellowHuman = (new 
YellowHumanFactory()).createHuman( ) ; 
yellowHuman.getColor(); 
yellowHuman. talk( ); 


证 


运行 结 末 还 是 相同 。 我 们 回顾 一 下 ， 每 一 个 产品 类 都 对 应 了 一 个 
创建 类 ， 好 处 就 是 创建 类 的 职员 清晰， 而且 结构 简单 ， 但 是 给 可 扩展 
性 和 可 维护 性 市 来 了 一 定 的 影响 。 为 什么 这 么 说 呢 ? 如 采 要 扩展 一 个 
产品 类 ， 就 需要 建立 一 个 相应 的 工厂 类 ， 这 样 就 增加 了 扩展 的 难度 。 


因为 工厂 类 和 产品 类 的 数量 相同 ， 维 护 时 需要 考虑 两 个 对 象 之 间 的 关 
系 。 


当然 ， 在 复杂 的 应 用 中 一 般 采 用 多 工厂 的 方法 ， 然 后 再 增加 一 个 
协调 类 ， 避 免 调 用 着 与 各 个 子 工 交流， 协调 类 的 作用 是 封 汉 子 工厂 
类 ， 对 高 层 模块 提供 统一 的 访问 接口 。 


3. 奉 代 单 例 模式 


第 7 章 讲 述 了 单 例 模 式 以 及 扩展 出 的 多 例 模式 ， 并 且 指出 了 单 例 和 
多 例 的 一 些 缺 点 ， 我 们 是 不 是 可 以 采用 工厂 方法 模式 实现 单 例 模 式 的 
功能 呢 ? 单 例 模式 的 核心 要 求 就 是 在 内 存 中 只 有 一 个 对 象 ， 通 过 工厂 
方法 模式 也 可 以 只 在 内 存 中 生产 一 个 对 象 ， 类 图 如 图 8-5 所 示 。 


-static Singleton singleton 3 nn) 


+void doSomething() 
图 8-5 工厂 方法 模式 替代 单 例 模式 类 图 
非常 简单 的 类 图 ，Singleton 定 义 了 一 个 private 的 无 参 构造 范 数 ， 目 
的 是 不 允许 通过 new 的 方式 创建 一 个 对 象 ， 如 代码 清单 8-20 所 示 。 
代码 清单 8-20 单 例 类 


public class Singleton { 
// 不 允许 通过 new 产 生 一 个 对 象 
private Singleton( ){ 


} 

public void doSomething(){ 
// 业 务 处 理 

} 


Singleton 保 证 不 能 通过 正 第 的 渠道 建立 一 个 对 象 ， 那 
SingletonFactory 如 何 建 立 一 个 单 例 对 象 呢 ? 答案 是 通过 反射 方式 创 
建 ， 如 代码 清单 8-21 所 示 。 


代码 清单 8-21 人 负责 生成 蛙 例 的 工厂 类 


public class SingletonFactory { 
private static Singleton singleton; 
statict{ 
try 1 
Class cl= 
Class.forName(Singleton.class.getName( )); 
// 获 得 无 参 构造 
Constructor 
constructor=cl.getDeclaredConstructor(); 
// 设 置 无 参 构造 是 可 访问 的 
constructor.setAccessible(true); 
// 产 生 一 个 实例 对 象 
singleton = 
(Singleton)constructor ,newInstance( ); 
} catch (Exception e) { 
// 寞 常 处 理 
} 


public static Singleton getSingleton(){ 
return singleton; 
} 


通过 获得 类 构造 吉 ， 然 后 设置 访问 权限 ， 生 成 一 个 对 象 ， 然 后 提 
供 外 部 访问 ， 保 证 内 存 中 的 对 象 唯一 。 当 然 ， 其 他 类 也 可 以 通过 反射 
的 方式 建立 一 个 单 例 对 象 ， 确 实 如 此 ， 但 是 一 个 项 目 或 团队 是 有 章程 


和 规范 的 ， 何 况 已 经 提供 了 一 个 获得 单 例 对 象 的 方法 ， 为 什么 还 要 重 
新 创建 一 个 新 对 象 呢 ? 除非 是 有 人 作恶 。 


以 上 通过 工厂 方法 模式 创建 了 一 个 单 例 对 象 ， 该 框架 可 以 继续 扩 
展 ， 在 一 个 项 目 中 可 以 产生 一 个 单 例 构 造 器 ， 所 有 需要 产生 单 例 的 类 
都 遵循 一 定 的 规则 (构造 方法 是 private) ， 然 后 通过 扩展 该 框架 ， 只 
输入 一 个 类 型 束 可 以 获得 唯一 的 一 个 实例 。 


4. 延迟 初 怒 化 


何 为 延迟 初始 化 (Lazy initialization) ? 一 个 对 象 被 消费 完毕 后 ， 
并 不 立刻 释放 ， 工 三 类 保持 其 初始 状态 ， 等 待 再 次 被 使 用 。 延 迟 初始 
化 是 工厂 方法 模式 的 一 个 扩展 应 用 ， 其 通用 类 图 如 图 8-6 所 示 。 


| 


+static fmal Map<String,Product> prMap = new HashMap() 
+void doSomething!{) 


tstatic synchronized Product createProduct(String type) 


ConcreteProduct 


1 
图 8-6 延迟 初始 化 的 通用 类 图 


ProductFactory 负 责 产 品类 对 象 的 创建 工作 ， 并 且 通 过 prMap 变 量 产 
生 一 个 缓存 ， 对 需要 再 次 被 重用 的 对 象 保留 ，Product 和 ConcreteProduct 


是 一 个 示例 代码 ， 请 参考 代码 清单 8-8 和 代码 清单 8-9。ProductFactory 如 


代码 清单 8-22 所 示 。 


代码 清单 8-22 延 返 加 载 的 工厂 类 


public class ProductFactory { 


private static final Map<String,Product> prMap = new 


HashMap( ); 


public static synchronized Product createProduct(String 


type) throws Exceptiont{ 
Product product =null; 
// 如 果 Map 中 已 经 有 这 个 对 象 
if(prMap.containskey(type))t 
product = prMap.get(type); 


}elsef 
if(type.equals("Product1"))t 


product = new ConcreteProduct1(); 


}elsef 


product = new ConcreteProduct2(); 


} 
// 同 时 把 对 象 放 到 绥 存 容器 中 
prMap.put(type,product); 


return product; 


代码 还 比较 简单 ， 定义 一 个 Map 容 项， 容纳 所 有 产生 的 对 象 ， 
如 采 在 Map 容 器 中 已 经 有 的 对 象 ， 则 直接 取出 返回 ， 如果 没有 ， 则 根据 
需要 的 类 型 产生 一 个 对 象 并 放 入 到 Map 容 器 中 ， 以 方便 下 次 调用 。 


延迟 加 载 框 架 是 可 以 扩展 的 ， 例 如 限制 某 一 个 产品 类 的 最 大 实例 


化 数量 ， 可 以 通过 判断 Map 中 已 有 的 对 象 数量 来 实现 ， 这 
常 有 意义 的 ， 例 如 JDBC 连 接 数据 库 ， 都 会 要 求 设 置 一 个 


MaxConnections 最 大 连接 数量 ， 该 数量 就 是 内 存 中 最 大 实例 化 的 数量 。 


延迟 加 载 还 可 以 用 在 对 象 初始 化 比较 复杂 的 情况 下 ， 例 如 硬件 访 
问 ， 涉 及 多 方面 的 交互 ， 则 可 以 通过 延迟 加 载 降低 对 象 的 产生 和 销毁 
市 来 的 复杂 性 。 


8.5 最 佳 实践 


工厂 方法 模式 在 项 目 中 使 用 得 非常 频 粽 ， 以 至 于 很 多 代码 中 都 包 
含 工厂 方法 模式 。 该 模式 几乎 尽 人 宵 知 ， 但 不 是 每 个 人 都 能 用 得 好 。 
熟 能 生 巧 ， 熟 练 掌握 该 模式 ， 多 思考 工厂 方法 如 何 应 用 ， 而 且 工 三 方 
法 模式 还 可 以 与 其 他 模式 混合 使 用 (例如 模板 方法 模式 、 单 例 模式 、 
原型 模式 等 ) ， 变 化 出 无 穷 的 优秀 设计 ， 这 也 正 是 软件 设计 和 开发 的 
乐趣 所 在 。 


第 9 章 ”抽象 工厂 模式 


9.1 女 娲 的 失 旋 


第 8 半 讲 了 女 娲 造 人 的 故事 。 人 是 造 出 来 了 ， 世 界 也 热 阅 了 ， 可 是 低头 一 
看 ， 都 是 清一色 的 类 型 ， 缺 少 关 爱 、 仇 恨 、 喜 奶 束 乐 等 情绪 ， 人 类 的 生命 太平 
淡 了 ， 女 娲 一 想 ， 猛 然 一 拍 脑 袋 ， 忘 记 给 人 类 定义 性 别 了 ， 那 怎么 办 ? 抹 掉 重 
来 ， 于 是 人 类 经 过 一 次 大 洗礼 ， 所 有 的 人 种 都 消炎 掉 了 ， 世 界 义 是 空 无 一 物 ， 
我 静 而 又 我 寅 。 


由 于 女 娲 之 前 的 准备 工作 花费 了 非常 大 的 精力 ， 比 如 准备 黄土 、 八 卦 炉 
等 ， 从 头 开始 建立 所 有 的 事物 也 是 不 可 能 的 ， 那 就 想 在 现 有 的 条 件 下 重新 造 
人 ， 尽 可 能 旧 物 利用 嘛 。 人 种 〈Product 产 品类 ) 应 该 怎么 改造 呢 ? 怎么 才能 让 
人 类 有 爱 有 恨 呢 ? 是 神仙 当然 有 办 法 了 ， 定 义 互 斥 的 性 别 ， 然 后 在 每 个 个 体 中 
埋 下 一 颗 种 子 : 异性 相 吸 ， 成 熟 后 就 一 定 会 去 找 个 异性 〈 这 就 是 我 们 说 的 爱情 
原动力 ) 。 从 设计 角度 来 看 ， 一 个 具体 的 对 象 通过 两 个 坐标 就 可 以 确定 : 肤色 
和 和 性别， 如 图 9-1 所 示 。 


女 男 性 淹 


图 9-1 肤色 性 别 坐 标 图 


产品 类 分 析 完 毕 了 ， 生 产 的 工厂 类 (八卦 炉 ) 该 怎么 改造 呢 ? 只 有 一 个 生 
产 设备 ， 要 么 生产 出 来 的 全 都 是 男性 ， 要 么 都 症 女 性 。 那 不 行 蚜 ， 这 么 翻天 禾 
地 的 改造 束 是 为 了 产生 不 同性 别 的 人 类 。 有 办 法 了 ! 把 目前 已 经 有 的 生产 设备 
一 一 八卦 炉 拆 开 ， 于 是 女 娲 就 使 用 了 “八卦 复制 术 ”， 把 原先 的 八卦 炉 一 个 变 两 
个 ， 并 且 略 加 修改 ， 就 成 了 女性 八卦 护 (只 生产 女性 人 种 ) 和 男性 八卦 炉 (只 
生产 男性 人 种 ) ， 于 是 乎 女 娲 就 开始 准备 生产 了 ， 其 类 图 如 图 9-2 所 示 。 


这 个 类 图 虽然 大 ， 但 是 比较 简单 。Java 的 典型 类 图 ， 一 个 接口 ， 多 个 抽象 
类 ， 然 后 是 N 个 实现 类 ， 每 个 人 种 都 是 一 个 抽象 类 ， 性 别 是 在 各 个 实现 类 中 实现 
的 。 特 别 需 要 说 明 的 是 HumanFactory 接 口 ， 在 这 个 接口 中 定义 了 三 个 方法 ， 分 
别 用 来 生产 三 个 不 同 肤色 的 人 种 ， 也 束 是 我 们 在 图 9-1 中 的 Y 坐 标 ， 它 的 两 个 实 
现 类 分 别 是 性 别 ， 也 就 是 图 9-1 中 的 X 坐 标 ， 通 过 X 坐 标 〈 性 别 ) 和 Y 坐 标 〈 肤 
色 ) 唯一 确定 了 一 个 生产 出 来 的 对 象 。 我 们 来 看 看 相关 的 实现 ，Human 接 口 如 
代码 清单 9-1 所 示 。 


<<interface>> 
Human 


tvoid getColor() 
tyokd talkO) 
+void getSexf) 


AbstractBlackHuman 

EE 
tvoid getColor(} 
+Void talk() 


AbstractWhiteHuman 
| 
tvoid getColor() 
+void talkO) 


AbstractYellowHuman 


| 
+void getColor() 
+void tak() 


FemaleBlackHuman 
EE 二 === 


tvoid getSex() 


MaleBlackHuman 
本 > 


tvoid getSex() 


<<interface>> 
HumanFactory 


HHuman createYellowHuman() 


+Human createWhiteHuman() 
HHuman createBlackHuman() 


FemaleFactory MaleFactory 


图 9-2 女 姻 重新 生产 人 类 


代码 清单 9-1 人 种 接口 


public interface Human { 
// 每 个 人 种 都 有 相应 的 颜色 
public void getCcolor() 
// 人 类 会 说 话 
public void talk(); 
// 每 个 人 都 有 性 别 
public void getSex(); 


人 种 有 三 个 抽象 类 ， 负 责 人 种 的 抽象 属性 定义 : 肤色 和 语言 。 白 色 人 种 、 
黑色 人 种 、 黄 色 人 种 分 别 如 代码 清单 9-2、 代 码 清单 9-3、 代 码 清单 9-4 所 示 。 


代码 清单 9-2 日 色 人 种 


public abstract class AbstractwhiteHuman implements Human { 
// 白 色 人 种 的 皮肤 颜色 是 白色 的 
public void getColor(){ 
System.out.println(" 白 色 人 种 的 皮肤 颜色 是 白色 的 !")，; 
} 


// 自 色 人 种 讲话 
public void talk() { 


System,out,.printJln(" 白 色 人 种 会 说 话 ， 一 般 说 的 都 是 单字 节 。" ) ; 
} 
} 
代码 清单 9-3 黑色 人 种 


public abstract class AbstractBlackHuman Implements Human { 
public void getColor(){ 
System.out.println(" 黑 色 人 种 的 皮肤 颜色 是 黑色 的 !")， 


} 

public void talk() { 
System.,out.println(" 黑 人 会 说 话 ， 一般人 听 不 懂 。")， 

} 


代码 清单 9-4 黄色 人 种 


public abstract class AbstractYellowHuman implements Human { 
public void getColor(){ 
System.out,println(" 黄 色 人 种 的 皮肤 颜色 是 黄色 的 ! ") ; 


} 

public void talk() { 
System.out.println(" 黄 色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 也 。" ) ) 

} 


每 个 抽象 类 都 有 两 个 实现 类 ， 分 别 实现 公共 的 最 细节 、 最 具体 的 事物 ， 肤 
色 和 语言 。 具 体 的 实现 类 实现 肤色 、 性 别 定义 ， 以 黄色 女性 人 种 为 例 ， 如 代码 
清单 9-5 所 示 。 


代码 清单 9-5 黄色 女性 人 种 


public class FemaleYellowHuman extends AbstractYellowHuman { 
// 黄 人 女性 
public void getSex() { 
System.out.,printlin(" 黄 人 女性 "); 
} 


黄色 男性 人 种 如 代码 清单 9-6 所 示 。 


代码 清单 9-6 黄色 男性 人 种 


public class MaleYellowHuman extends AbstractYellowHuman { 
// 黄 人 男性 
public void getSex() { 
System.out.println(" 黄 人 男性 "); 


其 他 的 黑色 人 人 种、 日 色 人 种 的 男性 和 女性 的 代码 与 此 类 似 ， 不 再 重复 编 
到 此 为 止 ， 我 们 已 经 把 真实 世界 的 人 种 都 定义 出 来 了 ， 剩 下 的 工作 束 是 怎 
么 制造 人 类 。 接 口 HumanFactory 如 代码 清单 9-7 所 示 。 


代码 清单 9-7 八卦 炉 定义 


public interface HumanFactory { 
// 制 造 一 个 黄色 人 种 
public Human createYellowHuman(); 
// 制 造 一 个 白色 人 种 
public Human createwhiteHuman(); 
// 制 造 一 个 黑色 人 种 
public Human createBlackHuman(); 


在 接口 中 ， 我 们 看 到 八卦 炉 是 可 以 生产 出 不 同 肤色 人 种 的 (当然 了 ， 女 娲 
的 失误 嘛 ) ， 那 它 有 多 少 个 八卦 炉 呢 ?两 个 ， 分别 生产 女性 和 男性 ， 女 性 和 男 
性 八卦 炉 分 别 如 代码 清单 9-8 和 代码 清单 9-9 所 示 。 


代码 清单 9-8 生产 女性 的 八卦 炉 


public class FemaleFactory implements HumanFactory { 
// 生 产 出 黑人 女性 

public Human createBlackHuman() { 
return new FemaleBlackHuman(); 


} 

// 生 产 出 白人 女性 

public Human createwhiteHuman() { 
return new FemalewhiteHuman(); 


} 

// 生 产 出 黄 人 女性 

public Human createYellowHuman() { 
return new FemaleYellowHuman( ) ， 

} 


代码 清单 9-9 生产 男性 的 八卦 炉 


public class MaleFactory implements HumanFactory { 
人 一 产 出 黑人 男性 
public Human createBlackHuman() { 
return new MaleBlackHuman(); 
} 


// 生 产 出 白人 男性 

public Human createwhiteHuman() { 
return new MalewhiteHuman(); 

} 


// 生 产 出 黄 人 男性 
public Human createYellowHuman() { 

return new MaleYellowHuman( ); 
} 


人 种 有 了 ， 八 卦 炉 也 有 了 ， 我 们 就 来 重 现 一 下 当年 女 娲 造 人 的 光景 ， 如 代 
码 清单 9-10 所 示 。 


代码 清单 9-10 女 娲 重 造 人 类 


public class NVWa { 
public static void main(String[] args) { 
// 第 一 条 和 生产线， 男性 生产 线 
HumanFactory maleHumanFactory = new MaleFactory(); 
// 第 二 条 和 生产线， 女性 生产 线 
HumanFactory femaleHumanFactory = new FemaleFactory( ) ， 
// 生 产 线 建立 完毕 ， 开 始 生产 人 了 : 
Human maleYellowHuman = 
maleHumanFactory.createYellowHuman(); 
Human femaleYellowHuman = 
femaleHumanFactory.createYellowHuman(); 
System.out.printlLn("--- 生 产 一 个 黄色 女性 - --")， 
femaleYellowHuman.getColor(); 
femaleYellowHuman. talk( ); 
femaleYellowHuman.getSex(); 
System.out .printlin("\n--- 生 产 一 个 黄色 男性 - --"); 
maleYellowHuman.getColor(); 
maleYellowHuman. talk(); 
maleYellowHuman.getSex(); 


三 


* 后 面 继续 创建 


| 


运行 结 琳 如 下 所 示 : 


一 生产 一 个 黄色 女性 --- 


色 人 种 的 皮肤 颜色 是 黄色 的 ! 


\m 
而 


色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 节 。 


\m 
测 


黄 人 女性 


一 生产 一 个 黄色 男性 --- 


黄色 人 种 的 皮肤 颜色 是 黄色 的 ! 


间 色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 节 。 


\m 


黄 人 男性 


各 种 肤色 的 男性 、 女 性 都 制造 出 来 了 ， 两 性 之 间 产 生 了 相互 吸引 力 ， 于 是 
情感 产生 ， 这 个 世界 就 多 了 一 种 小 说 的 题材 “爱情 ”。 回 头 来 想 想 我 们 的 设计 ， 
不 知道 大 家 有 没有 去 过 工厂 ， 每 个 工厂 分 很 多 车 间 ， 每 个 车 间 又 分 多 条 生产 
线 ， 分 别 生产 不 同 的 产品 ， 我 们 可 以 把 八卦 炉 比 喻 为 和 车间， 把 八卦 炉 生 产 的 工 
艺 (生产 白人 、 黑 人 还 是 黄 人 ) 称 为 生产 线 ， 如 此 来 看 就 是 一 个 女性 生产 车 
间 ， 专 门生 产 各 种 肤色 的 女性 ， 一 个 是 男性 生产 车 间 ， 专 门生 产 各 种 肤色 男 
性 ， 生 产 完 毕 就 可 以 在 系统 外 组 装 ， 什 么 是 组 装 ? 嘿嘿 ， 上 自己 思考 ! 在 这 样 的 
设计 下 ， 各 个 车 间 和 各 条 生产 线 的 职责 非常 明确 ， 在 车 间 内 各 个 生产 出 来 的 产 
品 可 以 有 耦合 关系 ， 你 要 知道 世界 上 黑 、 黄 、 白 人 种 的 比例 是 : 1:4:6， 那 这 就 
需要 女 娲 奶 奶 在 烧 制 的 时 候 就 要 做 好 比例 分 配 ， 在 一 个 车 间 内 协调 好 。 这 就 是 
抽象 工厂 模式 。 


el 


计 


9.2 抽象 工厂 模式 的 定义 
抽象 工厂 模式 (Abstract Factory Pattern) 是 一 种 比较 常用 的 模 
式 ， 其 定义 如 下 : 


Provide an interface for creating families of related or dependent 
objects without specifying their concrete classes. (为 创建 一 组 相关 或 相 
互 依赖 的 对 象 提 供 一 个 接口 ， 而 且 无 须 指 定 它 们 的 具体 类 。) 


抽象 工厂 模式 的 通用 类 图 如 图 9-3 所 示 。 


AbstractFactory AbstractProduct 


tHCreateProduct() 


ConcreteFactory | ConcreteProduct 


图 9-3 抽象 工厂 模式 的 通用 类 图 


抽象 工厂 模式 是 工厂 方法 模式 的 升级 版 本 ， 在 有 多 个 业务 品种 、 
业务 分 类 时 ， 通 过 抽象 工厂 模式 产生 需要 的 对 象 是 一 种 非常 好 的 解决 
方式 。 我 们 来 看 看 抽象 工厂 的 通用 源 代 码 ， 首 先 有 两 个 互相 影响 的 产 
品 线 〈 也 叫做 产品 族 ) ， 例 如 制造 汽车 的 左 侧门 和 右 侧 门 ， 这 两 个 应 
该 是 数量 相等 的 一 一 两 个 对 象 之 间 的 约束 ， 每 个 型 号 的 车 门 都 是 不 一 
样 的 ， 这 是 产品 等 级 结构 约束 的 ， 我 们 先 看 看 两 个 产品 族 的 类 图 ， 如 
图 9-4 所 示 。 


ApbstractProductA 


| 


ApbstractProductB 


ProductB[2| 


| 


a 


AbstractCreator 


de ord) 
EE | 


图 9-4 抽象 工厂 模式 的 通用 源码 类 图 


注意 类 图 上 的 圈 圈 、 框 框 相对 应 ， 两 个 抽象 的 产品 类 可 以 有 关 
系 ， 例 如 共同 继承 或 实现 一 个 抽象 类 或 接口 ， 其 源 代码 如 代码 清单 9- 
11 所 示 。 


代码 清单 9-11 抽象 产品 类 


public abstract class AbstractProductA { 
// 每 个 产品 共有 的 方法 
public void shareMethod(){ 


} 
// 每 个 产品 相同 方法 ， 不 同 实现 
public abstract void doSomething(); 


两 个 具体 的 产品 实现 类 如 代码 清单 9-12、 代 码 清单 9-13 所 示 。 


代码 清单 9-12 产品 Al 的 实现 类 


public class ProductA1 extends AbstractProductA { 
public void doSomething() { 
System,out.printlLn(" 产 品 A1 的 实现 方法 " ) ， 
} 


代码 清单 9-13 产品 A2 的 实现 类 


public class ProductA2 extends AbstractProductA { 
public void doSomething() { 
System,out.println(" 产 品 A2 的 实现 方法 " ) ， 
} 


产品 B 与 此 类 似 ， 不 再 玫 述 。 抽 象 工 厂 类 AbstractCreator 的 职责 是 
定义 每 个 工厂 要 实现 的 功能 ， 在 通用 代码 中 ， 抽 象 工 厂 类 定义 了 两 个 
产品 族 的 产品 创建 ， 如 代码 清单 9-14 所 示 


[© 


代码 清单 9-14 抽象 工厂 类 


public abstract class AbstractCreator { 
// 创 建 A 产品 家 族 
public abstract AbstractProductA createProductA( ) ; 
// 创 建 B 产 品 家 族 
public abstract AbstractProductB createProductB( ) ; 


注意 ”有 N 个 产品 族 ， 在 抽象 工厂 类 中 就 应 该 有 N 个 创建 方法 。 


如 何 创建 一 个 产品 ， 则 是 由 具体 的 实现 类 来 完成 的 ，Creator1 和 


Creator2 如 代码 清单 9-15 和 代码 清单 9-16 所 示 。 


代码 清单 9-15 产品 等 级 1 的 实现 类 


public class Creator1 extends AbstractCreator 
// 只 生产 产品 等 级 为 1 的 A 产 品 
public AbstractProductA createProductA( ) 
return new ProductA1( ) ; 
} 


// 只 生产 产品 等 级 为 1 的 B 产 品 

public AbstractProductB createProductB() 
return new ProductB1( ) ; 

} 


代码 清单 9-16 产品 等 级 2 的 实现 类 


public class Creator2 extends AbstractCreator 
// 只 生产 产品 等 级 为 2 的 A 产品 
public AbstractProductA createProductA() 
return new ProductA2( ); 
} 


// 只 生产 产品 等 级 为 2 的 B 产 品 

public AbstractProductB createProductB() 
return new ProductB2(); 

} 


注意 ”有 M 个 产品 等 级 就 应 该 有 M 个 实现 工 ) 
三 中 ， 实 现 不 同 产 品 族 的 生产 任务 。 


{ 


{ 
{ 


类 ， 在 每 个 实现 工 


在 具体 的 业务 中 如 何 产 生 一 个 与 实现 无 关 的 对 象 呢 ? 如 代码 清单 


9-17 所 示 。 


代码 清单 9-17 场景 类 


public class Client { 


public static void main(String[] args) { 


// 定 义 出 两 个 


AbstractCreator creator1 
AbstractCreator creator2 


| 
new Creator1(); 
new Creator2(); 


// 产 生 A1 对 象 
AbstractProductA a1i = creator1.createProductA( ) ; 
// 产 生 A2 对 象 
AbstractProductA a2 = creator2.createProductA( ); 
// 产 生 B1 对 象 
AbstractProductB b1 = creator1.createProductB( ) ， 
// 产 生 B2 对 象 
AbstractProductB b2 = creator2.createProductB(); 
pA 

* 然后 在 这 里 就 可 以 为 所 欲 为 了 ... 

A 


在 场景 类 中 ， 没 有 任何 一 个 方法 与 实现 类 有 关系 ， 对 于 一 个 产品 
来 说 ， 我 们 只 要 知道 它 的 工厂 方法 束 可 以 直接 产生 一 个 产品 对 象 ， 无 


须 关 心 它 的 实现 类 。 


9.3 抽象 工 上 模式 的 应 用 


9.3.1 抽象 工厂 模式 的 优点 


e 封装 性 ， 每 个 产品 的 实现 类 不 是 高 层 模块 要 关心 的 ， 它 要 关心 
的 是 什么 ? 是 接口 ， 是 抽象 ， 它 不 关心 对 象 是 如 何 创建 出 来 ， 这 由 谁 
负责 呢 ? 工厂 类 ， 只 要 知道 工厂 类 古 谁 ， 我 束 能 创建 出 一 个 需要 的 对 
象 ， 省 时 省 力 ， 优 秀 设 计 就 应 该 如 此 。 


e 广 品 族 内 的 约束 为 非 公开 状态 。 例 如 生产 男女 比例 的 问题 上 ， 
家 想 女 娲 女 召 肯定 有 目 己 的 打算 ， 不 能 让 女 盛 男 肥 ， 否 则 女性 的 优点 
不 就 体现 不 出 来 了 吗 ? 那 在 抽象 工厂 模式 ， 就 应 该 有 这 样 的 一 个 约 
束 : 每 生产 1 个 女性 ， 就 同时 生产 出 1.2 个 男性 ， 这 样 的 生产 过 程 对 调 
用 工厂 类 的 高 层 模 块 来 说 是 透明 的 ， 它 不 需要 知道 这 个 约束 ， 我 就 十 
要 一 个 黄色 女性 产品 束 可 以 了 ， 具 体 的 产品 族 内 的 约束 古 在 工厂 内 实 
现 的 。 


9.3.2 抽象 工厂 模式 的 缺点 


抽象 工厂 模式 的 最 大 缺点 束 是 产品 族 扩展 非常 困难 ， 为 什么 这 人 么 
说 呢 ? 我 们 以 通用 代码 为 例 ， 如 果 要 增加 一 个 产品 C， 也 吏 是 说 产品 


家 族 由 原来 的 2 个 增加 到 3 个 ， 看 看 我 们 的 程序 有 多 大 改动 吧 ! 抽象 类 
AbstractCreator 要 增加 一 个 方法 createProductCO， 然 后 两 个 实现 类 都 要 
修改 ， 想 想 看 ， 这 严重 违反 了 开 闭 原则 ， 而 且 我 们 一 直 说 明 抽 象 类 和 
接口 是 一 个 契约 。 改 变 契 约 ， 所 有 与 契约 有 关系 的 代码 都 要 修改 ， 那 
么 这 段 代 码 叫 什么 ? 叫 “ 有 毒 代 码 ”， 天 系 ， 束 
可 能 产生 侵害 的 危险 ! 


9.3.3 抽象 工厂 模式 的 使 用 场景 


抽象 工厂 模式 的 使 用 场景 定义 非常 简单 : 一 个 对 象 族 (或 是 一 组 
没有 任何 关系 的 对 象 ) 都 有 相同 的 约束 ， 则 可 以 使 用 抽象 工厂 模式 。 
什么 意思 呢 ? 例如 一 个 文本 编辑 器 和 一 个 图 片 处 理 郝 ， 都 是 软件 实 
体 ， 但 是 nix 下 的 文本 编辑 器 和 Windows 下 的 文本 编辑 器 虽然 功能 和 
界面 都 相同 ， 但 是 代码 实现 古 不 同 的 ， 图 片 处 理 右 也 有 类 似 情况 。 也 
忠 是 具有 了 共同 的 约束 条 件 ， 操 作 系统 类 型 。 于 是 我 们 可 以 使 用 抽象 
工厂 模式 ， 产 生 不 同 操作 系统 下 的 编辑 器 和 图 片 处 理 器 


9.3.4 抽象 工厂 模式 的 注意 事项 


在 抽象 工厂 模式 的 缺点 中 ， 我 们 提 到 抽象 工厂 模式 的 产品 
比较 困难 ， 但 是 一 定 要 清楚 ， 是 产品 族 扩 展 困 难 ， 而 不 古 产 品 等 级 。 
在 该 模式 下 ， 产 品 等 级 是 非常 容易 扩展 的 ， 增 加 一 个 产品 等 


增加 一 个 工厂 类 负责 新 增加 出 来 的 产品 生产 任务 即 可 。 也 就 是 说 横 疝 
扩展 容易 ， 纵 同 扩 展 困难 。 以 人 类 为 例子 ， 产 品 等 级 中 只 有 男 、 女 两 
个 性 别 ， 现 实 世界 还 有 一 种 性 别 : 双 性 人 ， 既 是 男人 也 是 女人 (俗语 
就 是 阴阳 人 ) ， 那 我 们 要 扩展 这 个 产品 等 级 也 是 非常 容易 的 ， 增 加 三 
个 产品 类 ， 分 别 对 应 不 同 的 肤色 ， 然 后 再 创建 一 个 工厂 类 ， 专 门 负责 
不 同 肤色 人 的 双 性 人 的 创建 任务 ， 完 全 通过 扩展 来 实现 需求 的 变更 ， 
从 这 一 点 上 看 ， 抽 和 象 工 三 模式 征 符合 开 闭 原则 的 。 


9.4 最 佳 实践 


一 个 模式 在 什么 情况 下 才能 够 使 用 ， 是 很 多 读者 比较 困惑 的 地 

方 。 抽 象 工厂 模式 古 一 个 简单 的 模式 ， 使 用 的 场景 非常 多 ， 大 家 在 软 
件 产 品 开发 过 程 中 ， 涉 及 不 同 操作 系统 的 时 候 ， 都 可 以 考虑 使 用 抽象 
工厂 模式 ， 例 如 一 个 应 用 ， 需 要 在 三 个 不 同 平台 (Windows 、Linux、 
Android (Google 发 布 的 智能 终端 操作 系统 ) ) 上 运行 ， 你 会 怎么 设 
计 ? 分 别 设 计 三 套 不 同 的 应 用 ? 非 也 ， 通 过 抽象 工厂 模式 屏蔽 挥 操作 
系统 对 应 用 的 影响 。 三 个 不 同 操作 系统 上 的 软件 功能 、 应 用 逻辑 、UI 
都 应 该 是 非常 类 似 的 ， 唯 一 不 同 的 是 调用 不 同 的 工 上 方 法 ， 由 不 同 的 
产品 类 去 处 理 与 操作 系统 交互 的 信息 。 


第 10 章 ”模板 方法 模式 


10.1 辉煌 工程 ”制造 悍马 


周三 ，9:00， 我 刚刚 坐 到 位 置 上 ， 打 开 电 脑 准 备 开 始 干 活 。 


“小 三 ， 小 三 ， 叫 一 下 其 他 同事 ， 到 会 议 室 开会 ”>， 老 大 跑 过 来 
吼 ， 认 着 坏 笑 。 还 没 等 大 家 坐 稳 ， 老 大 就 开讲 了 : 


“告诉 大 家 一 个 好 消 轧 ， 上 昨天 终于 把 xx 模型 公司 的 口子 打开 了 ， 要 
我 们 做 悍马 模型 ,虽然 是 第 一 个 车 辆 模型 ， 但 是 我 们 有 能 力 、 有 信心 
做 好 ， 我 们 一 定 要 ......”( 中 间 省 略 20 分 钟 的 讲话 ， 如 果 你 听 过 领导 
的 讲话 ， 这 个 你 应 该 能 够 续 上 ) 


动员 工作 做 完了 ， 那 整 开 始 压 任务 了 。“ 这 次 时 间 是 非常 紧张 的 ， 
只 有 一 个 星期 的 时 间 ， 小 三 ， 你 负责 在 一 个 星期 的 时 间 把 这 批 10 万 车 
模 ( 注 ， 车 模 是 车 辆 模型 的 意思 ， 不 是 香 车 美女 那个 车 模 ) 建设 完 


“一 个 星期 ? 这 个 .…… 征 真 做 不 完 ， 要 做 分 析 ， 做 模板 ， 做 测试 ， 
还 要 考虑 扩展 性 、 稳 定性 、 健 壮 性 等 ， 时 间 实 在 是 太 少 了 。 ”还 没 等 
大 说 完 ， 我 束 急 了 ， 再 不 急 我 的 小 命 束 折 在 上 面 了 |! 


“ 那 这 样 ， 只 做 最 基本 的 实现 ， 不 考虑 太 多 的 问题 ， 怎 么 样 ? ” 老 
大 又 把 我 弹 回 去 了 。 


“只 作 基 本 实现 ? 那 ..……” 


唉 ， 领 导 已 经 布置 任务 了 ， 那 束 开 始 拼 命 地 做 吧 。 然 后 就 开始 准 
钾 动 手 做 ， 在 做 之 前 先 介绍 一 下 我 们 公司 的 痛 景 ， 我 们 公司 是 做 模型 
生产 的 ， 做 过 桥架 模型 、 建 筑 模型 、 机 械 模 型 ， 甚 至 是 一 些 政府 、 军 
事 的 机 密 模 型 ， 这 个 不 能 细 说 ， 绝 密 。 公 司 的 主要 业务 束 是 把 实物 按 
照 一 定 的 比例 缩小 或 放大 ， 用 于 试验 、 分 析 、 量 化 或 者 是 销售 ， 等 
等 ， 上 面 提 到 的 xx 模型 公司 是 专门 销售 车 辆 模型 的 公司 ， 目 己 没有 生 
产 企业 ， 全 部 是 代 工 。 我 们 公司 是 第 一 次 从 xx 模型 公司 接 单 ， 那 我 怎 
么 着 也 要 把 活 干 好 ， 可 时 间 有 限 ， 任 务 量 又 巨大 ， 怎 么 办 ? 


既然 领导 都 说 了 ， 不 考虑 扩展 性 ， 那 好 办 ， 移 按照 最 一 般 的 经 验 
设计 类 图 ， 如 图 10-1 所 示 。 


HummerModel 定义 一 个 抽象 类 ， 悍 马车 模型 ~ 
start0) 启 动车 辆 
tvoid start() stop0) 停 止 车 辆 
5 OM 
| engineBoom() 引 擎 发 出 艇 鸣 声 


tvoid engineBoom() 
t+void run() run0 汽车 跑 起 来 


HummerH2Model 
呈 二 二 == > 


图 10-1 悍马 车 模型 最 一 般 的 类 图 


非常 简单 的 实现 ， 悍 马车 有 两 个 型 号 ，H1 和 H2。 按 照 需求 ， 只 需 
要 悍马 模型 ， 那 好 我 就 给 你 悍马 模型 ， 驳 写 个 抽象 类 ， 然 后 两 个 不 同 
型 号 的 模型 实现 类 ， 通 过 们 单 的 继承 束 可 以 实现 业务 要 求 。 我 们 先 从 
抽象 类 开始 编写 ， 抽 象 悍马 模型 如 代码 清单 10-1 所 示 。 

代码 清单 10-1 抽象 悍马 模型 
ot class HummerModel { 


* 首先 ， 这 个 模型 要 能 够 被 发 动 起 来 ， 别 管 是 手 播发 动 ， 还 是 电力 发 动 ， 反 正 
Sl E 够 发 动 起 来 ， 那 这 个 实现 要 在 实现 类 里 了 


i abstract void start(); 
// 能 发 动 ， 还 要 能 停 下 来 ， 那 才 是 真 本 事 
public abstract void stop() ; 


// 喇 叭 会 出 声音 ， 是 滴 滴 叫 ， 还 是 哗 哗 叫 

public abstract void alarm( ); 

/V 引 擎 会 疤 隆 隆 地 响 ， 不 响 那 是 假 的 

public abstract void engineBoom( ) ; 

// 那 模型 应 该 会 跑 吧 ， 别 管 是 人 推 的 ， 还 是 电力 驱动 的 ， 总 之 要 会 跑 
public abstract void run(); 


在 抽象 类 中 ， 我 们 定义 了 悍马 模型 都 必须 具有 的 特质 ， 能 够 发 
动 、 停 止 ， 喇叭 会 啊 ， 引 苟 可 以 艇 呜 ， 而 且 还 可 以 停止 。 但 十 每 个 型 
号 的 悍马 实现 是 不 同 的 ，H1 型 号 的 悍马 如 代码 清单 10-2 所 示 。 


代码 清单 10-2 H1 型 号 悍马 模型 


public class HummerH1iModel extends HummerModel { 

//H1 型 号 的 悍马 车 鸣 笛 
public void alarm() { 

System,out,println(" 悍 马 H1 鸣 笛 ..."); 


// 引 警 颖 鸣 声 
public void engineBoom() { 
System.out.println(" 悍 马 H1 引 警 声音 是 这 样 的 , . ."); 


} 

// 汽 车 发 动 

public void start() { 
System.out.println(" 悍 蕊 Hi 发 动 ,.."); 

} 


// 停 车 
public void stop() { 
System.out.println(" 悍 马 H1 停 车 ..."); 


} 

// 开 动 起 来 

public void run()t{ 
// 先 发 动 汽车 
this.start(); 
/V/ 引 擎 开始 邦 哆 
this.engineBoom() ; 
// 然 后 就 开始 跑 了 ， 跑 的 过 程 中 遇 到 一 条 狗 挡 路 ， 就 按 喇 叭 
this.alarm(); 
// 到 达 目 的 地 就 停车 
this.stop( ); 


大 家 注意 看 run() 方 法 ， 


这 束 是 一 种 检验 方法 ， 让 它 跑 起 来 ! 通 


所 有 功能 都 测试 到 了 。 


是 一 个 汇总 的 方法 ， 一 个 模型 生产 成 功 
， 总 要 拿 给 客户 检测 吧 ， 怎 么 检测 ?“ 征 桑子 是 马 ， 拉 出 去 溜溜 ”， 


H2 型 号 悍马 如 代码 清单 10-3 所 示 。 


代码 清单 10-3 H2 型 号 悍马 模型 


public class HummerH2Model extends HummerModel { 


//H2 型 号 的 悍马 车 鸣 征 
public void alarm() { 


System,out.println(" 悍 马 H2 鸣 笛 .， 


} 
/V 引 警 萎 鸣 声 


public void engineBoom() { 
System,out,.println(" 悍 马 H2 引 擎 声 


下 
// 汽 车 发 动 
public void start() { 


System.out.printlin(" 悍 蕊 H2 发 动 ,，,， 


i 
// 停 车 
public void stop() { 


System.out .printlLn(" 悍 马 H2 停 车 .. 


} 

// 开 动 起 来 

public void run(){ 
// 先 发 动 汽车 
this.start(); 
/V/ 引 擎 开始 邦 哆 


2 


过 run0 这 样 的 方法 ， 把 模型 的 


this.engineBoom( ); 


// 然 后 就 开始 跑 了 ， 


this.alarm(); 
// 到 达 目 的 地 就 停 
this.stop(); 


跑 的 过 程 中 遇 到 


在 


是 这 档 


0 


一 条 狗 挡 路 ， 


Ef 在... ) ; 


就 按 喇 叭 


好 了 ， 程 序 编写 到 这 里 ， 已 经 发 现 问题 了 ， 两 个 实现 类 的 run() 方 
法 部 是 完全 相同 的 ， 那 这 个 run0) 方 法 的 实现 应 该 出 现在 抽象 类 ， 不 应 
该 在 实现 类 上 ， 抽 象 是 所 有 子 类 的 共性 封装 。 


注意 ”在 软件 开发 过 程 中 ， 如 果 相 同 的 一 段 代 码 复制 过 两 次 ， 束 
需要 对 设计 产生 怀疑 ， 架 构 师 要 明确 地 说 明 为 什么 相同 的 逻辑 要 出 现 
两 次 或 更 多 次 。 


好 ， 问 题 发 现 了 ， 我 们 就 需要 马上 更 改 ， 修 改 后 的 类 图 如 图 10-2 所 


定义 一 个 抽象 类 ， 悍马 车 模型 ~ 
start() 启 动车 
stop() 停 止 车 辆 


HummerModel 
EE 
+vVoid start() 
+vVoid stop!() 
+vVoid alarm!) 
+Void eneineBoom!) 


二 Vold runt( 


alarm0 喇 叭 呜 叫 
engineBoom0 引 警 发 出 萎 鸣 


run() 汽 车 跑 起 来 


HummerH2Model 
| 


图 10-2 修改 后 的 悍马 车 模 类 图 


HummerHlModel 
于 
| 


注意 ， 抽 象 类 HummerModel 中 的 run0 方 法 ， 由 抽象 方法 变更 为 实 
现 方 法 ， 其 源 代 码 如 代码 清单 10-4 所 示 。 


代码 清单 10-4 修改 后 的 抽象 悍马 模型 


public abstract class HummerModel { 
/* 


* 首先 ， 这 个 模型 要 能 发 动 起 来 ， 别 管 是 手 摇 发 动 ， 还 是 电力 发 动 ， 反 正 
* 是 要 能 够 发 动 起 来 ， 那 这 个 实现 要 在 实现 类 里 了 

*/ 

public abstract void start(); 

// 能 发 动 ， 还 要 能 停 下 来 ， 那 才 是 真 本 事 

public abstract void stop(); 

// 喇 叭 会 出 声音 ， 是 滴 滴 叫 ， 还 是 哗 哗 叫 

public abstract void alarm(); 

// 引 警 会 到 隆隆 地 响 ， 不 响 那 是 假 的 


public abstract void engineBoom( ) ， 
// 那 模型 应 该 会 跑 吧 ， 别 管 是 人 推 的 ， 还 是 电力 驱动 ， 总 
public void run(){ 
// 先 发 动 汽车 
this.start(); 
// 引 警 开 始 释 鸣 
this.engineBoom( ); 
// 然 后 就 开始 跑 了 ， 跑 的 过 程 中 遇 到 一 条 狗 挡 路 ， 就 按 喇 叭 
this.alarm(); 
// 到 达 目 的 地 就 停车 
this.stop( ); 


ct 
~ 
问 
> 
是 


在 抽象 的 悍马 模型 上 已 经 定义 了 run() 方 法 的 执行 规则 ， 先 局 动 ， 
然后 引擎 立刻 爱 鸣 ， 中 间 还 要 按 一 下 喇叭 ， 制 造 点 噪声 (要 不 就 不 是 
名 车 了 ) 。 然 后 停车 ， 它 的 两 个 具体 实现 类 就 不 需要 实现 run() 方 法 
了 ， 只 要 把 代码 清单 10-2、 代 码 请 单 10-3 上 的 run0) 方 法 删除 即 可 ， 不 再 
资 述 代码 。 


场景 类 实现 的 任务 就 是 把 生产 出 的 模型 展现 给 客户 ， 其 源 代码 如 
代码 清单 10-5 所 示 。 


代码 清单 10-5 场景 


public class Client { 
public static void main(String[] args) { 
//XX 公 司 要 H1 型 号 的 悍马 
HummerModel hi = new HummerH1iModel](); 
//Hi 模 型 演示 
hi.run(); 


一 


运行 结果 如 下 所 示 。 


悍马 H1 发 动 ... 


悍马 H13 引 警 声 音 是 这 样 的 … 


悍马 H1 鸣 笛 .… 


悍马 H1 停 车 .… 

目前 客户 只 要 看 H1 型 号 的 悍马 车 ， 没 问题 ， 生 产 出 来 ， 同 时 可 以 
运行 起 来 给 他 看 看 。 非 党 简单 ， 那 如 采 我 告诉 你 这 融 是 模板 方法 模式 
你 会 不 会 很 不 悄 呢 ? 束 这 模式 ， 太 简单 了 ， 我 一 直 在 使 用 呀 ! 是 的 ， 
你 经 党 在 使 用 ， 但 你 不 知道 这 是 模板 方法 模式 ， 那 些 所 谓 的 高 手 束 可 
以 很 牛 地 说 : “用 模板 方法 模式 就 可 以 实现 ”， 你 还 要 很 崇拜 地 看 着 ， 
哇 ， 牛 人 ,模板 方法 模式 是 什么 呀 ?这 束 古 模板 方法 模式 。 


10.2 模板 方法 模式 的 定义 


模板 方法 模式 (Template Method Pattern) 是 如 此 简单 ， 以 致 让 你 感觉 你 已 
经 能 够 掌握 其 精 散 了 。 其 定义 如 下 : 


Define the skeleton of an algorithm in an operation,deferring some steps to 
subclasses.Template Method lets subclasses redefine certain steps of an algorithm 
without changing the algorithm's structure. (定义 一 个 操作 中 的 算法 的 框架 ， 而 将 
一 些 步 又 延迟 到 子 类 中 。 使 得 子 类 可 以 不 改变 一 个 算法 的 结构 即 可 重 定义 该 算 
法 的 某 些 特定 步骤 。) 


模板 方法 模式 的 通用 类 图 如 图 10-3 所 示 。 


AbstractClass 


| 8 
tHyoid doAnything() 
#yoid doSomething() 
+void template Method() 


ConcreteClassl 


图 10-3 修改 后 的 悍马 车 模 类 图 


模板 方法 模式 确实 非常 简单 ， 仅 仅 使 用 了 Java 的 继承 机 制 ， 但 它 是 一 个 应 
用 非常 广泛 的 模式 。 其 中 ，AbstractClass 叫 做 抽象 模板 ， 它 的 方法 分 为 两 类 : 


e 基本 方法 


用 。 


基本 方法 也 叫做 基本 操作 ， 是 由 子 类 实现 的 方法 ， 并 且 在 模板 方法 被 调 


e 模板 方法 


可 以 有 一 个 或 几 个 ， 一 般 是 一 个 具体 方法 ， 也 就 是 一 个 框架 ， 实 现 对 基本 


方法 的 调度 ， 完 成 固定 的 逻辑 。 


注意 为 
六 局 ， 


I 


了 防止 恶意 的 操作 ， 一 般 模板 方法 都 加 上 final 关 键 字 ， 不 允许 被 


在 类 图 中 还 有 一 个 角色 : 具体 模板 。ConcreteClass1 和 ConcreteClass2 属 于 具 


体 模 板 ， 实 现 父 类 所 定义 的 一 个 或 多 个 抽象 方法 ， 也 就 是 父 类 定义 的 基本 方法 


在 子 类 中 得 以 实现 。 


我 们 来 看 其 通用 代码 ，AbstractClass 如 代码 清单 10-6 所 示 。 


代码 清单 10-6 抽象 模板 类 


public abstra 


ct class AbstractClass { 


// 基 本 方法 


protecte 


d abstract void doSomething(); 


// 基 本 方法 


protecte 


// 模 板 方法 


public v 


d abstract void doAnything(); 


oid templateMethod(){ 
pA 


* 调用 基本 方法 ， 完 成 相关 的 逻辑 
*/ 

this.doAnything(); 
this.doSomething(); 


具体 模板 如 代码 清单 10-7 所 示 。 


代码 清单 10-7 具体 模板 类 


public class ConcreteClass1 extends AbstractClass { 
// 实 现 基本 方法 
protected void doAnything() { 
// 业 务 逻 辑 处 理 


} 

protected void doSomething() { 
// 业 务 逻 辑 处 理 

} 


public class ConcreteClass2 extends AbstractClass { 
// 实 现 基本 方法 
protected void doAnything() { 
// 业 务 逻 辑 处 理 


} 

protected void doSomething() { 
// 业 务 逻 辑 处 理 

} 


场景 类 如 代码 清单 10-8 所 示 。 


代码 清单 10-8 场景 类 


public class Client { 
public static void main(String[] args) { 
AbstractClass classi1 = new ConcreteClass1(); 
AbstractClass class2 = new ConcreteClass2(); 
// 调 用 模板 方法 
class1.templateMethod( ); 
class2.templateMethod( ); 


注意 ”抽象 模板 中 的 基本 方法 尽量 设计 为 protected 类 型 ， 符 合 迪 米 特 法 
则 ， 不 需要 骏 露 的 属性 或 方法 尽量 不 要 设置 为 protected 类 型 。 实 现 类 寿 非 必要 ， 
尽量 不 要 扩大 父 类 中 的 访问 权限 。 


10.3 模板 方法 模式 的 应 用 
10.3.1 模板 方法 模式 的 优点 


。 封 装 不 变 部 分 ， 扩 展 可 变 部 分 


把 认为 是 不 变 部 分 的 算法 封 流 到 父 类 实现 ， 而 可 变 部 分 的 则 可 以 
通过 继承 来 继续 扩展 。 在 悍马 模型 例子 中 ， 是 不 是 束 非 常 容易 扩展 ? 
例如 增加 一 个 H3 型 号 的 悍马 模型 ， 很 容易 呀 ， 增 加 一 个 子 类 ， 实 现 父 
类 的 基本 方法 就 可 以 了 。 


e 提取 公共 部 分 代码 ， 便 于 维护 


我 们 例子 中 刚刚 走 过 的 弯路 就 十 最 好 的 证 明 ， 如 有 果 我 们 不 抽取 到 
父 类 中 ， 任 由 这 种 散乱 的 代码 发 生 ， 想 想 后 果 是 什么 样子 ? 维护 人 员 
为 了 修正 一 个 缺陷， 需要 到 处 查找 类 似 的 代码 ! 


e 行为 由 父 类 控制 ， 子 类 实现 


基本 方法 是 由 子 类 实现 的 ， 因 此 子 类 可 以 通过 扩展 的 方式 增加 相 
应 的 功能 ， 符 合 开 闭 原则 。 


10.3.2 模板 方法 模式 的 缺点 


按照 我 们 的 设计 习惯 ， 抽 象 类 负责 声明 最 抽象 、 最 一 般 的 事物 属 
性 和 方法 ， 实 现 类 完成 具体 的 事物 属性 和 方法 。 但 是 模板 方法 模式 却 
颠倒 了 ， 抽 和 象 类 定义 了 部 分 抽象 方法 ， 由 子 类 实现 ， 子 类 执行 的 结 采 
影响 了 父 类 的 结果 ， 也 就 是 子 类 对 父 类 产生 了 影响 ， 这 在 复 灯 的 项 目 

会 市 来 代码 阅读 的 难度 ， 而 且 也 会 让 新 手 产 生 不 适 感 。 


10.3.3 模板 方法 模式 的 使 用 场景 


e 多 个 子 类 有 公有 的 方法 ， 并 且 逻 辑 基 本 相同 时 。 


e 重要 、 复 洒 的 算法 ， 可 以 把 核心 算法 设计 为 模板 方法 ， 周 边 的 
相关 细 市 功能 则 由 各 个 子 类 实现 。 
e 重 构 时 ， 模 板 方 法 模式 是 一 个 经 党 使 用 的 模式 ， 把 相同 的 代码 


抽取 到 父 类 中 ， 然 后 通过 钩子 画 数 ( 见 “模板 方法 模式 的 扩展 ”) 约束 
其 行为 。 


10.4 模板 方法 模式 的 扩展 


到 目前 为 止 ， 这 两 个 模型 都 稳定 地 运行 ， 突 然 有 一 天 ， 老 大 急 匆 
匆 地 找到 了 我 : 


“看 你 怎么 设计 的 ， 车 子 一 司 动 ， 喇 叭 就 狂 啊 ， 吵 死人 了 ! 客户 提 
出 H1 型 号 的 悍马 喇叭 想 让 它 啊 惑 啊 ，H2 型 号 的 喇叭 不 要 有 声音 ， 赶 快 
修改 一 下 。” 


自己 车 的 祸 ， 就 要 想 办 法 解决 它 ， 稍 稍 思考 一 下 ， 解 决 办 法 有 
了 ， 先 画 出 类 图 ， 如 图 10-4 所 示 。 


HummerModel 


tyvoid start() 
#void stopl) 


#yvoid alarm!() 

tyvoid engine Boom!() 
+void run() 

#boolean isAlarm() 


HummerH2Model 


+Vold setAlarm(boolean isAlarm) 


图 10-4 扩展 悍马 车 模 类 图 


类 图 改动 似乎 很 小 ， 在 抽象 类 HummerModel 中 增加 了 一 个 实现 方 
法 isAlarm， 确 定 各 个 型 号 的 悍马 是 否 需 要 声 首 ， 由 各 个 实现 类 莉 写 该 
方法 ， 同 时 其 他 的 基本 方法 由 于 不 需要 对 外 提供 访问 ， 因 此 也 设计 为 
protected 类 型 。 其 源 代码 如 代码 清单 10-9 所 示 。 


代码 清单 10-9 扩展 后 的 抽象 模板 类 


public abstract class HummerModel { 
/* 


Fal 


* 首先 ， 这 个 模型 要 能 够 被 发 动 起 来 ， 别 管 是 手 播发 动 ， 还 是 电力 发 动 ， 反 正 
* 是 要 能 够 发 动 起 来 ， 那 这 个 实现 要 在 实现 类 里 
WA 
protected abstract void start(); 
// 能 发 动 ， 还 要 能 停 下 来 ， 那 才 是 真 本 事 
本 abstract void stop() 
// 喇 叭 会 出 声音 ， 是 滴 滴 叫 ， 还 是 蜂 哗 吕 
Bvteoted abstract void alarm(); 
// 引 擎 会 笑 隆 隆 的 响 ， 不 响 那 是 假 的 
protected abstract void engineBoom(); 
// 那 模型 应 该 会 跑 吧 ， 别 管 是 人 推 的 ， 还 是 电力 驱动 ， 总 之 要 会 跑 
final public void run() { 
// 先 发 动 汽 车 
this.start(); 
/V/ 引 擎 开始 缀 鸣 
this.engineBoom( ) ; 
// 要 让 它 叫 的 束 是 束 叫 ， 喇 嘛 不 想 让 它 啊 驶 不 啊 
if(this.isAlarm()){ 

this.alarm( ); 


} 
// 到 达 目 的 地 就 停车 
this.stop(); 


} 

// 钩 子 方法 ， 默 认 喇 叭 是 会 响 的 
protected boolean 1ISAJLarm( ){ 
return true ， 

} 


~ 


在 抽象 类 中 ，isAlarm 是 一 个 实现 方法 。 其 作用 是 模板 方法 根据 其 

返回 值 决定 是 否 要 响 喇 叭 ， 子 类 可 以 履 写 该 返回 值 ， 由 于 H1 型 号 的 喇 

叭 是 想 让 它 响 就 响 ， 不 想 让 它 响 就 不 响 ， 由 人 控制 ， 其 源 代码 如 代码 
清单 10-10 所 示 。 


代码 清单 10-10 扩展 后 的 H1 悍 马 


public class HummerHiModel extends HummerModel { 
private boolean alarmFlag = true; // 要 响 喇 叭 
protected void alarm() { 
System.out.printlLn(" 悍 马 H1 鸣 笛 ...")，) 


protected void 
System 


protected void 


System. 


protected void 


System. 


engineBoom() { 


.out.println(" 悍 马 H1 引 擎 声音 是 这 样 的 . ， 
Start() { 

out .printlLn(" 悍 马 H1 发 动 . ,."); 
stop() { 


out .println(" 悍 马 H1 停 车 ...")， 


protected boolean isAlarm() { 


return 


} 
// 要 不 要 啊 喇 叭 ， 


this.alarmFlag; 


是 由 客户 来 决定 的 


public void setAlarm(boolean isAlarm){ 


2 


this.alarmFlag = isAlarm; 
} 
} 
只 要 调用 H1 型 号 的 悍马 ,默认 是 有 喇叭 啊 的 ， 当 然 你 可 以 不 让 喇 
中 \H 呵 ， 通 过 isAlarm(false) 束 可 以 实现 。H2 型 号 的 悍 蕊 是 没有 喇叭 声响 
的 ， 其 源 代码 如 代码 清单 10-11 所 示 。 


代码 清单 10-11 扩展 后 的 H2 悍 马 


public class HummerH2Model extends HummerModel { 


protected void 
System 


protected void 


System. 


protected void 
System 


protected void 


System. 


3 
// 默 认 没 有 喇叭 的 


.Out .printJln(" 悍 马 H2 鸣 笛 . ， 


alarm() { 


a 


engineBoom() { 


out .println(" 悍 马 H23 引 警 声 音 是 这 样 的 ,. 


start() { 


.oUt .printlin(" 悍 马 H2 发 动 ,.."); 


stop() { 


out .println(" 悍 马 H2 停 车 ...")， 


protected boolean isAlarm() { 


return 


false; 


这 入 


H2 型 号 的 悍马 设置 isAlarm() 的 返回 值 为 false， 也 就 是 关闭 了 喇叭 
功能 。 场 景 类 代码 如 代码 清单 10-12 所 示 。 


代码 清单 10-12 扩展 后 的 场景 类 


public class Client { 
public static void main(String[] args) throws IOException 
{ 


System,.out.println("------- H1 型 号 悍马 -------- 2 

System.out.printlLln("H1 型 号 的 悍马 是 否 需要 喇叭 声响 ? 0- 不 
需要 “ 1- 需要 " ) ) 

String type=(new BufferedReader(new 
InputStreamReader (System.in))).readLine( ); 

HummerHiModel hi = new HummerH1iModel( ); 

if(type.equals("0"))t{ 

hi.setAlarm(false); 


} 

hi.run( ); 

System.out.printin("\n------- H2 型 号 悍马 -------- 有 
HummerH2Model h2 = new HummerH2Model( ) ; 

h2.run( ); 


运行 是 需要 交互 的 ， 首 先 ， 要 求 输入 H1 型 号 的 悍马 是 否 有 声音 ， 
如 下 所 示 : 


-~ H1 型 号 悍马 -------- 


H1 型 号 的 悍马 是 否 需 要 喇叭 声响 ? 0- 不 需要 1- 需 要 


输入 “0” 后 的 运行 结果 如 下 所 示 : 


， H1 型 号 悍马 -------- 


H1 型 号 的 悍马 是 否 需要 喇叭 声响 ”0- 不 需要 1- 需 要 


0 


悍马 H1 发 动 .. 


悍马 H2 发 动 .. 


悍马 H2 引 擎 声音 是 这 样 的 … 


悍马 H2 停 车 .. 


-~ H1 型 号 悍马 -------- 


H1 型 号 的 悍马 是 否 需 要 喇叭 声响 ? 0- 不 需要 1- 需 要 


1 


悍马 H1 发 动 ... 


悍马 H1 引 警 声音 是 这 样 的 .… 


悍马 H1 鸣 笛 .. 


悍马 H2 引 擎 声音 是 这 样 的 … 


看 到 没 ，HI1 型 号 的 悍马 是 由 客户 自己 控制 是 否 要 响 喇 叭 ， 也 就 是 
说 外 界 条 件 改 变 ， 影 响 到 模板 方法 的 执行 。 在 我 们 的 抽象 类 中 isAlarm 
的 返回 值 就 是 影响 了 模板 方法 的 执行 结果 ， 该 方法 就 叫做 钧 子 方法 
(Hook Method) 。 有 了 钩子 方法 模板 方法 模式 才 算 完 美 ， 大 家 可 以 
想 想 ， 由 子 类 的 一 个 方法 返回 值 决定 公共 部 分 的 执行 结果 ， 是 不 是 很 
有 吸引 力 呀 ! 


模板 方法 模式 就 是 在 模板 方法 中 按照 一 定 的 规则 和 顺序 调用 基本 
方法 ， 具 体 到 前 面 那个 例子 ， 就 是 run0) 方 法 按照 规定 的 顺序 ( 先 调用 
start()， 然 后 再 调用 engineBoom()， 再 调用 alarm()， 最 后 调用 stop()) 调 
用 本 类 的 其 他 方法 ， 并 且 由 isAlarm() 方 法 的 返回 值 确定 run0 中 的 执行 
顺序 变更 。 


10.5 最 住 实践 


初级 程序 员 在 写 程序 的 时 候 经 常会 问 高 手 “ 父 类 怎么 调用 子 类 的 方 
法 ”。 这 个 问题 很 有 普 忆 性 ， 反 正 我 是 被 问 过 好 几 回 ， 那 么 父 类 有 是否 可 
以 调用 子 类 的 方法 呢 ? 我 的 回答 是 能 ， 但 强烈 地 、 极 度 地 不 建议 这 人 么 
做 ， 那 该 怎么 做 呢 ? 


e 把 了 于 类 传递 到 父 类 的 有 参 构造 中 ， 然 后 调用 。 


e 使 用 反射 的 方式 调用 ， 你 使 用 了 反射 还 有 谁 不 能 调用 的 ? ! 


e 父 类 调用 子 类 的 静态 方法 。 


这 三 种 都 是 父 类 直接 调用 子 类 的 方法 ， 好 用 不 ? 好 用 ! 解决 问题 
了 吗 ? 解决 了 ! 项 目 中 允许 使 用 不 ? 不 允许 ! 我 就 一 直 没 有 搞 懂 为 什 
么 要 用 父 类 调用 子 类 的 方法 。 如 采 一 定 要 调用 子 类 ， 那 为 什么 要 继承 
它 呢 ? 搞 不 懂 。 其 实 这 个 问题 可 以 换个 角度 去 理解 ， 父 类 建立 框 染 ， 
子 类 在 重 写 了 父 类 部 分 的 方法 后 ， 再 调用 从 父 类 继承 的 方法 ， 产 生 不 
同 的 结果 《而 这 正 是 模板 方法 模式 ) 。 这 是 不 是 也 可 以 理解 为 父 类 调 
用 了 子 类 的 方法 呢 ? 你 修改 了 子 类 ， 影 响 了 父 类 行为 的 结 采 ， 曲 线 救 
国 的 方式 实现 了 父 类 依赖 子 类 的 场景 ， 模 板 方 法 模式 束 是 这 种 效 采 。 


模板 方法 在 一 些 开 谣 框 架 中 应 用 非常 多 ， 它 提供 了 一 个 抽象 类 ， 
然后 开源 框架 写 了 一 堆 子 类 。 在 《xxx In Action》 中 就 说 明了 ， 如 果 
你 需要 扩展 功能 ， 可 以 继承 这 个 抽象 类 ， 然 后 黎 写 protected 方 法 ， 再 
然后 殉 是 调用 一 个 类 似 execute 方 法 ， 束 完成 你 的 扩展 开发 ， 非 常 容易 
扩展 的 一 种 模式 。 


第 11 章 ”建造 着 模式 


奔 要 化 是 永 但 的 


又 是 一 个 周三 ， 快 要 下 班 了 ， 老 大 突然 拉 住 我 ， 喜 洲 滋 地 告诉 我 : “xx 公司 很 满意 
我 们 做 的 模型 ， 又 签订 了 一 个 合同 ， 把 奔驰 、 宝 马 的 车 辆 模型 都 交 给 我 们 公司 制作 了 ， 
不 过 这 次 又 额外 增加 了 一 个 者 需求 : 汽车 的 启动 、 停 止 、 喇 叭 声音 、 引 擎 声音 都 由 客户 
自己 控制 ， 他 想 什么 顺序 就 什么 顺序 ， 这 个 没 问 题 吧 ? ” 


那 任务 又 是 一 个 时 间 紧 、 工 程 量 大 的 项 目 ， 为 什么 是 “又 ? 呢 ? 因为 基本 上 每 个 项 目 
都 是 如 此 ， 我 该 怎么 来 完成 这 个 任务 呢 ? 


首先 ， 我 们 分 析 一 下 需求 ， 奔 驰 、 宝 马 都 是 一 个 产品 ， 它 们 有 共有 的 属性 ，xx 公 司 
关心 的 是 单个 模型 的 运行 过 程 : 奔驰 模型 A 是 先 有 引 警 声音， 然后 再 响 喇叭 ;奔驰 模型 B 
是 先 启动 起 来 ， 然 后 再 有 引 警 声音， 这 才 是 xx 公 司 要 关心 的 。 那 到 我 们 老大 这 边 呢 ， 就 
是 满足 人 家 的 要 求 ， 要 什么 顺序 就 立马 能 产生 什么 顺序 的 模型 出 来 。 我 就 负责 把 老大 的 
要 求实 现 出 来 ， 而 且 还 要 是 批量 的 ， 也 就 是 说 xx 公司 下 单 订购 宝马 A 车 模 ， 我 们 老大 马 
上 就 找 我 生产 一 个 这 样 的 车 模 ， 启 动 完毕 后 ， 喇 叭 响 一 下 ”， 然 后 我 们 就 准备 开始 批量 
生产 这 些 模型 。 由 我 生产 出 N 多 个 奔驰 和 宝马 车 辆 模型 ， 这 些 车 辆 模型 都 有 run() 方 法 ， 

具体 到 每 一 个 模型 的 run() 方 法 中 间 的 执行 任务 的 顺序 是 不 同 的 ， 老 大 说 要 啥 顺序 ， 
我 就 给 啥 顺序 ， 最 终 客户 买 走 后 只 能 是 既定 的 模型 。 好 ， 需 求 还 是 比较 复杂 ， 我 们 先 一 
个 一 个 地 解决 ， 先 从 找 一 个 最 简单 的 切入 点 一 一 产品 类 ， 每 个 车 都 是 一 个 产品 ， 如 图 11- 
1 所 示 。 


CarModel 


#yoid start() 

#yoid stop() 

#yvoid alarm() 

#yoid engineBoom!() 

+void run() 

+vold setSequence(ArrayList sequence) 


BenzModel BM WModel 


he 二 、 clip 、 ~ 
奔驰 实现 类 宝马 实现 类 


图 11-1 汽车 模型 类 图 


类 图 比较 人 简单， 在 CarModel 中 我 们 定义 了 一 个 setSequence 方 法 ， 车 辆 模型 的 这 几 个 
动作 要 如 何 排 布 ， 是 在 这 个 ArrayList 中 定义 的 。 然 后 run0 方 法 根据 sequence 定 义 的 顺序 
完成 指定 的 顺序 动作 ， 与 第 10 章 介绍 的 模板 方法 模式 是 不 是 非常 类 似 ?” 好 ， 我 们 先 看 
CarModel 源 代码 ， 如 代码 清单 11-1 所 示 。 


代码 清单 11-1 车 辆 模型 的 抽象 类 


public abstract class CarModel { 
// 这 个 参数 是 各 个 基本 方法 执行 的 顺序 
private ArrayList<String> sequence = new ArrayList<String>(); 
// 模 型 是 启动 开始 跑 ] 
ee abstract void start(); 
能 发 动 ， 还 要 能 停 下 来 ， 那 才 是 真 本 事 
pe abstract void stop() 
// 喇 叭 会 出 声音 ， 是 滴 滴 叫 ， 还 是 哗 哗 叫 
protected abstract void alarm(); 
// 引 擎 会 轰隆 隆 地 响 ， 不 响 那 是 假 的 
protected abstract void engineBoom(); 
// 那 模型 应 该 会 跑 吧 ， 别 管 是 人 推 的 ， 还 是 电力 驱动 ， 总 之 要 会 跑 
final public void run() { 
// 循 环 一 边 ， 谁 在 前 ， 就 先 执行 谁 
for(int i=0;i<this.sequence.size();i++){ 
string actionName = this.sequence.get(i); 


~ 


if(actionName.equalsIgnoreCase("start"))t{ 
this,.start(); // 启 动 汽 车 
}else if(actionName.equalsIgnoreCase("stop"))t{ 
this.stop(); // 停 止 汽车 
}else if(actionName.equalsIgnoreCase("alarm"))t 
this.alarm(); // 喇 叭 开始 叫 ] 
}else if(actionName.equalsIgnoreCase("engine boom"))t{ 
// 如 果 是 engine boom 关 


键 字 
this.engineBoom(); /引擎 开始 纱 鸣 
} 
} 
} 坟 ,+ 1 ~ ND 
// 把 传递 过 来 的 值 传递 到 类 内 
final public void setSequence(ArrayList sequence)t{ 
this.sequence = sequence; 
} 
} 


CarModel 的 设计 原理 是 这 样 的 ，setSequence 方 法 是 允许 客户 自己 设置 一 个 顺序 ， 是 
要 移 启动 响 一 下 喇叭 再 跑 起 来 ， 还 是 要 移 响 一 下 喇叭 再 启动。 对 于 一 个 具体 的 模型 永远 
都 固定 的 ， 但 是 对 N 多 个 模型 就 是 动态 的 了 。 在 子 类 中 实现 父 类 的 基本 方法 ，run0 方 法 
读 取 sequence， 然 后 遍历 sequence 中 的 字符 串 ， 哪 个 字符 串 在 先 ， 就 先 执行 哪个 方法 。 


两 个 实现 类 分 别 实现 父 类 的 基本 方法 ， 奔 驰 模型 如 代码 清单 11-2 所 示 。 


代码 清单 11-2 奔驰 模型 代码 


public class BenzModel extends CarModel { 


protected void alarm() { 
System.out.println(" 奔 驰 车 的 喇叭 声音 是 这 个 样子 的 ..."); 


protected void engineBoom( ) { 
System.out .println(" 奔 驰 
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车 的 引擎 是 这 个 声音 的 ...")， 


} 
protected void start() { 
System,out,println(" 奔 驰 车 跑 起 来 是 这 个 样子 的 , ,,") ; 


} 
protected void stop() { 
System.out.println(" 奔 邓 车 应 该 这 样 停车 . . .") ; 


宝马 车 模型 如 代码 清单 11-3 所 示 。 


代码 清单 11-3 宝马 模型 代码 


public class BMWwModel extends CarModel { 
protected void alarm() { 


System,out,println(" 宝 马车 的 喇叭 声音 是 这 个 样子 的 ,, ,") ; 
protected void engineBoom( ) { 
System.out.printlLn(" 宝 马车 的 引擎 是 这 个 声音 的 . . .") ; 
protected void start() { 
System.out.printin(" 宝 马车 跑 起 来 是 这 个 样子 的 ,,.,"); 
protected void stop() { 
System.out.println(" 宝 马车 应 该 这 样 停车 ...")， 
} 
} 

两 个 产品 的 实现 类 都 完成 ， 我 们 来 模拟 一 下 xx 公司 的 要 求 : 生产 一 个 奔驰 模型 ， 要 
求 跑 的 时 候 ， 移 发 动 引 擎 ， 然 后 再 挂 挡 局 动 ， 然 后 停 下 来 ， 不 需要 喇叭 。 这 个 需求 很 容 
易 满足 ， 我 们 增加 一 个 场景 类 实现 该 需求 ， 如 代码 清单 11-4 所 示 。 

代码 清单 11-4 奔驰 模型 代码 
public class Client { 

public static void main(String[] args) { 

A* 

* 客户 告诉 XX 公司 ， 我 要 这 样 一 个 模型 ， 然 后 XX 公司 就 告诉 我 老大 
* 说 要 这 样 一 个 模型 ， 这 样 一 个 顺序 ， 然 后 我 就 来 制造 

*/ 

BenzModel] benz = new BenzModel(); 

// 存 放 run 的 顺序 


ArrayL 


Sedquence ,add("engine boom"); 


sequen 
sequen 


ist<String> sequence 


// 
// 


ce.add("start"); 
ce.add("stop"); 


new ArrayList<String>(); 


// 客 户 要 求 ，run 的 时 候 先 发 动 引 警 
启动 起 来 
了 一 段 就 停 下 来 


满足 了 xx 公司 的 需求 。 但 是 
门 只 满足 了 一 个 需求 ， 还 有 下 


// 我 们 把 这 个 顺序 赋予 奔驰 车 
benz.setSequence(sequence); 
benz.run(); 
} 
} 
运行 结果 如 下 所 示 : 
奔驰 车 的 引擎 是 这 个 声音 的 ..… 
奔驰 车 跑 起 来 是 这 个 样子 的 .… 
奔驰 车 应 该 这 样 停车 .… 
看 ， 我 们 组 装 了 这 样 的 一 辆 汽车 ， 
车 的 动作 执行 顺序 是 要 能 够 随意 调整 的 。 我 人 
多 伏 后 是 第 二 个 宝马 模型 ， 只 要 启动 停止 ， 


旦 相 术 


AE /BN 


其 他 的 什么 都 不 要 ; 第 三 


我们 的 需求 ， 汽 
一 个 需求 蚜 ， 
先 喇叭 ， 


个 模型 ， 


然后 局 动 ， 然 后 停止 ， 第 四 个 .…... 直 到 把 你 副 疯 为 止 ， 那 怎么 办 ? 我 们 莽 一 个 一 个 地 来 
写 场景 类 满足 吗 ? 不 可 能 了 ， 那 我 们 要 想 办 法 来 解决 这 个 问题 ， 有 了 ! 我 们 为 每 种 模型 
产品 模型 定义 一 个 建造 者 ， 你 要 蛤 顺序 直接 告诉 建造 者 ， 由 建造 者 来 建造 ， 于 古 乎 我 们 
就 有 了 如 图 11-2 所 示 的 类 图 。 


CarBuilder CarModel 
+void setSequence(ArrayList sequence) #yo id start() 
tCarModel getCarModel() #yoid stop() 
#void alarml() 
A #yoid engineBoom() 
+void run() 
+void setSequence(ArrayList sequence) 


BenzBuilder BMWBuilder " n 


BenzModel BMWModel 


弃 驰 车 的 组 续 


弃 台 实现 类 宇 马 实现 类 


图 11-2 增加 了 建造 者 的 汽车 模型 类 图 


增加 了 一 个 CarBuilder 抽 和 象 类 ， 由 它 来 组 装 各 个 车 模 ， 要 什么 类 型 什么 顺序 的 车 辆 模 
型 ， 都 由 相关 的 子 类 完成 。 首 先 编写 CarBuilder 代 码 ， 如 代码 清单 11-5 所 示 。 


Wz 


代码 清单 11-5 抽象 汽车 组 装 者 


public abstract class CarBuilder { 
// 建 造 一 个 模型 ， 你 要 给 我 一 个 顺序 要 求 ， 就 是 组 装 顺 序 
public abstract void setSequence(ArrayList<String> sequence); 
// 设 置 完毕 顺序 后 ， 就 可 以 直接 拿 到 这 个 车 辆 模型 
public abstract CarModel getCarModel(); 


很 简单 ， 每 个 车 辆 模型 都 要 有 确定 的 运行 顺序 ， 然 后 才能 返回 一 个 车 辆 模型 。 奔 驰 
车 的 组 装 者 如 代码 清单 11-6 所 示 。 


代码 清单 11-6 奔驰 车 组 装 者 


public class BenzBuilder extends CarBuilder { 
private BenzModel benz = new BenzModel(); 
public CarModel getCarModel() { 
return this.benz; 


public void setSequence(ArrayList<String> sequence) { 
this.benz.setSequence(sequence); 


} 


非常 简单 实用 的 程序 ， 


定 一 个 汽车 的 运行 顺序 ， 然 后 就 返回 一 个 奔驰 车 ， 简 单 了 


很 多 。 宝 马车 的 组 装 与 此 相同 ， 如 代码 清单 11-7 所 示 。 


代码 清单 11-7 宝 


马车 组 装 者 


public class BMWBuilder extends CarBuilder { 
private BMWModel bmw = new BMwModel(); 
public CarModel getCarModel() { 


return 


this .bmw; 


public void setSequence(ArrayList<String> sequence) { 
this.bmw.setSequence(sequence); 


} 


两 个 组 装 者 都 完成 了 ， 我 们 再 来 看 看 xx 公司 的 需求 如 何 满足 ， 修 改 一 下 场景 类 ， 如 


代码 清单 11-8 所 示 。 


代码 清单 11-8 修改 后 的 场景 类 


public class Client 


{ 


public static void main(String[] args) { 


As 


* 客户 告诉 XX 公司 ， 


* 说 要 这 样 一 个 模型 ， 


本 


我 要 这 样 一 个 模型 ， 然 后 XX 公 司 就 告诉 我 老大 


// 存 放 run 的 顺序 
ArrayList<String> sequence = new ArrayList<String>(); 
sequence.add("engine boom"); // 客 户 要 求 ，run 时 候 时 候 先 发 动 引 警 


sequence.add("start"); // 启 动 起 来 


这 样 一 个 顺序 ， 然 后 我 就 来 制造 


sequence.add("stop");  ”// 开 了 一 段 就 停 下 来 


// 要 一 个 


奔驰 车 : 


BenzBuilder benzBuilder = new BenzBuilder(); 


// 把 顺 户 


给 这 个 builder 类 ， 制 造 出 这 样 一 个 车 出 来 


benzBuilder.setSequence(sequence); 


// 制 造 出 


上 一 个 奔驰 车 


BenzModel] benz = 
// 奔 驰 车 跑 一 下 看 看 
benz.run(); 
} 
} 
运行 结果 如 下 所 示 : 


(BenzModel )benzBuilder .getCarModel(); 


奔驰 车 的 引擎 是 这 个 声音 的 … 


奔驰 车 跑 起 来 是 这 个 样子 的 … 


奔驰 车 应 该 这 样 停车 … 


那 如 果 我 再 想 要 个 同样 顺序 的 宝马 车 呢 ? 很 简单 ， 再 次 修改 一 下 场景 类 ， 如 代码 清 
单 11-9 所 示 。 


代码 清单 11-9 相同 顺序 的 宝马 车 的 场景 类 


public class Client { 
public static void main(String[] args) { 

// 存 放 run 的 顺序 
ArrayList<String> sequence = new ArrayList<String>(); 
sequence.add("engine boom"); // 客 户 要 求 ，run 的 时 候 先 发 动 引 擎 
sequence.add("start"); // 启 动 起 来 
sequence.add("stop"); // 开 了 一 段 就 停 下 来 
// 要 一 个 奔驰 车 : 
BenzBuilder benzBuilder = new BenzBuilder(); 
// 把 顺序 给 这 个 builder 类 ， 制 造 出 这 样 一 个 车 出 来 
benzBuilder.setSequence(sequence); 
// 制 造 出 一 个 奔驰 车 
BenzModel] benz = (BenzModel)benzBuilder.getCcarModel(); 
// 奔 驰 车 跑 一 下 看 看 
benz.run(); 
// 按 照 同样 的 顺序 ， 我 再 要 一 个 宝马 
BMWBuilder bmwBuilder = new BMWBuilder(); 
bmwBuilder .setSequence(sequence); 
BMWModel bmw = (BMWwModel)bmwBuilder.getCarModel(); 
bmw.run( ); 


运行 结果 如 下 所 示 : 


奔驰 车 的 引擎 是 这 个 声音 的 … 


奔驰 车 跑 起 来 是 这 个 样子 的 … 


奔驰 车 应 该 这 样 停车 … 


宝马 车 的 引擎 是 这 个 声音 的 .… 


宝马 车 跑 起 来 是 这 个 样子 的 .… 


宝马 车 应 该 这 样 停车 .. 


看 ， 同 样 运行 顺 序 的 宝马 车 也 生产 出 来 了 ， 而 且 代码 是 不 是 比 刚 开始 直接 访问 产品 
类 (Procuct) 简单 了 很 多 。 我 们 在 做 项 目 时 ， 经 常会 有 一 个 共识 : 需求 是 无 底 洞 ， 是 了 
理性 的 ， 不 可 能 你 告诉 它 不 增加 需求 就 不 增加 ， 这 4 个 过 程 《start、stop、alarm、engine 
boom) 按照 排列 组 合 有 很 多 种 ，xx 公 司 可 以 随意 组 合 ， 它 要 什么 顺序 的 车 模 我 就 必须 生 
成 什么 顺序 的 车 模 ， 客 户 可 是 上 帝 ! 那 我 们 不 可 能 预知 他 们 要 什么 顺序 的 模型 呀 ， 怎 
办 ? 封装 一 下 ， 找 一 个 导演 ， 指 挥 各 个 事件 的 先后 顺序 ， 然 后 为 每 种 顺序 指定 一 个 代 


[om 


码 ， 你 说 一 种 我 们 立刻 避 ® 给 你 生产 处 理 ， 好 方法 ， 历 害 ! 我 们 先 修改 一 下 类 图 ， 如 图 11- 


3 所 示 。 


+CarModel getABenzModel() 
+CarModel] getBBenzModel() 
+CarModel getCBMWModel() 
+CarModel getDBMWModel() 


CarModel 


CarBuilder 
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+void setSequencelArrayList sequence) 3 #void startl) 
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#yoid alarm() 

#yoid engineBoom!() 
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奔驰 实现 类 已 蕊 实现 类 


| 奔驰 车 的 组 装 


| 宝马 车 的 组 装 


图 11-3 完整 汽车 模型 类 图 


类 图 看 着 复 杀 了 ， 但 还 是 比较 简单 ， 我 们 增加 了 一 个 Director 类 ， 负 责 按照 指定 的 顺 
序 生产 模型 ， 其 中 方法 说 明 如 下 : 


TT 


e getABenzModel 方 法 


组 建 出 A 型 号 的 奔驰 车 辆 模型 ， 其 过 程 为 只 有 启动 (start) 、 停 止 (stop) 方法 ， 其 
他 的 引擎 声音 、 喇 叭 都 没有 。 


e getBBenzModel 方 法 


组 建 出 B 型 号 的 奔驰 车 ， 其 过 程 为 先 发 动 引擎 (engine boom) ， 然 后 启动 ， 再 然后 
停车 ， 没 有 喇叭 。 


e getCBMWModel 方 法 


组 建 出 C 型 号 的 宝马 车 ， 其 过 程 为 先 喇叭 叫 一 下 (alarm) ， 然 后 启动 ， 再 然后 是 停 


e getDBMWModel 方 法 


组 建 出 D 型 号 的 宝马 车 ， 其 过 程 训 一 个 启动 ， 然 后 一 路 跑 到 黑 ， 永 动机 ， 没 有 停止 
方法 ， 没 有 喇叭 ， 没 有 引擎 到 鸣 。 


其 他 的 FE 型号、F 型 号 ...... 可 以 有 很 多 ， 启 动 、 人 和 停止、 喇叭、 引擎 胡 鸣 这 4 个 方法 在 
这 个 类 中 可 以 随意 地 自由 组 合 。Director 类 如 代码 清单 11-10 所 示 。 


| 


代码 清单 11-10 导演 类 


public class Director { 
private ArrayList<String> sequence = new ArrayList(); 
private BenzBuilder benzBuilder = new BenzBuilder(); 
private BMWBuilder bmwBuilder = new BMWBuilder(); 


Ze 
* A 类 型 的 奔驰 车 模型 ， 先 start， 然 后 stop， 其 他 什么 引擎 、 喇 叭 一 概 没有 
*/ 
public BenzModel ee 
// 清 理 场景 ， 这 里 是 一 些 初 级 程序 员 不 注意 的 地 方 


this. a clear(); 


//ABenzMode1 的 执行 顺序 

this.sequence.add("start"); 
this.sequence.add("stop"); 

// 按 照 顺 序 返回 一 个 奔驰 车 
this.benzBuilder.setSequence(this.sequence); 
return (BenzModel)this.benzBuilder.getCarModel(); 


} 
双关 
* B 型 号 的 奔驰 车 模型 ， 是 先 发 动 引擎 ， 然 后 启动 ， 然 后 停止 ， 没 有 喇叭 
*/ 
public BenzModel] getBBenzModel(){ 
this.sequence.clear(); 
this.sequence.add("engine boom"); 
this.sequence.add("start"); 
this.sequence.add("stop"); 
this.benzBuilder.setSequence(this.sequence); 
return (BenzModel)this.benzBuilder.getCarModel(); 


} 
/* 
* C 型 号 的 宝马 车 是 先 按 下 喇叭 〈 炫 犹 嘛 ) ， 然 后 启动 ， 然 后 停止 
*/ 
public BMWModel getCBMWModel( ){ 
this.sequence.clear(); 
this.sequence.add("alarm"); 
this.sequence.add("start"); 
this.sequence.add("stop"); 
this.bmwBuilder.setSequence(this.sequence); 
return (BMWwModel)this.bmwBuilder.getCarModel(); 


} 
A 
* D 类 型 的 宝马 车 只 有 一 个 功能 ， 就 是 跑 ， 启 动 起 来 就 跑 ， 永 远 不 停止 
*/ 
public BMWModel getDBMWModel(){ 
this.sequence.clear(); 
this.sequence.add("start"); 
this.bmwBuilder.setSequence(this.sequence); 
return (BMwModel)this.benzBuilder.getCarModel(); 


} 

/* 

* 这 里 还 可 以 有 很 多 方法 ， 你 可 以 先 停止 ， 然后 再 启动 ， 或 才 停 着 不 动 ， 
* 导演 类 嘛 ， 按 照 什么 顺序 是 导演 说 了 算 

WA 


静态 的 嘛 


顺便 说 一 下 ， 大 家 看 一 下 程序 中 有 很 多 this 调 用 。 这 个 我 一 般 是 这 样 要 求 项 目 组 成 员 


的 ， 如 采 你 要 调用 类 中 的 成 员 变 量 或 方法 ， 


跑 起 来 ， 但 是 不 清晰 ， 加 上 this 关 键 字 ， 我 就 是 要 调用 本 类 


本 方法 中 的 一 个 变量 。 还 有 super 方 法 也 是 一 术 


需要 在 前 面 加 上 this 关 键 字 ， 不 加 也 能 正常 地 


的 成 员 变量 或 方法 ， 而 不 是 


， 是 调用 父 类 的 成 员 变量 或 者 方法 ， 那 就 


加 上 这 个 关键 字 ， 不 要 省 略 ， 这 要 靠 约束 ， 还 有 就 是 程序 员 的 自 


改 ， 那 中 也 没 招 。 


他 


是 死 不 悔 


注意 ”上 面 每 个 方法 都 有 一 个 this.sequence.clear()， 估 计 你 一 看 就 明白 。 但 是 作为 

个 系统 分 析 师 或 是 技术 经 理 一 定 要 告诉 项 目 成 员 ，ArrayList 和 HashMap 如 果 定 义 成 类 的 
成 员 变 量 ， 那 你 在 方法 中 的 调用 一 定 要 做 一 个 clear 的 动作 ， 以 防止 数据 混乱 。 如 果 你 发 
生 过 一 次 类 似 问题 的 话 ， 比 如 ArrayList 中 出 现 一 个 “出 乎 意料 ”的 数据 ， 而 你 又 花费 了 几 
个 通宵 才 解 决 这 个 问题 ， 那 你 会 有 很 深刻 的 印象 。 


有 了 这 样 一 个 导演 类 后 ， 我 们 的 场景 类 就 更 容易 处 理 了 ，xx 公 司 要 A 类 型 的 奔驰 车 1 
万 辆 ，B 类 型 的 奔驰 车 100 万 辆 ，C 类 型 的 宝马 车 1000 万 辆 ，D 类 型 的 不 需要 ， 非 常 容易 
处 理 ， 如 代码 清单 11-11 所 示 。 


代码 清单 11-11 导演 类 


public class Client { 
public static void main(String[] args) { 
Director director = new Director(); 
//1 万 辆 A 类 型 的 奔驰 车 
for(int i=0;i<10000;i++){ 
director.getABenzModel( ) .run(); 


} 

//1009 万 辆 B 类 型 的 奔驰 车 

for(int i=0;i<1000000;i++){ 
director.getBBenzModel().run(); 


} 
//1090 万 辆 C 类 型 的 宝马 车 
for(int i=0;i<10000000;i++){ 

director ,getCBMWModel().run( )， 
} 


青 晰 、 人 简单 吧 ， 我 们 写 程序 重 构 的 最 终 目 的 就 是 ， 简单、 清晰 。 代 码 是 让 人 看 的 ， 
不 是 写 完 就 完事 了 ， 我 一 直 在 教育 我 带 的 团队 成 员 ，Java 程 序 不 是 像 我 们 前 硬 写 二 进 制 
代码 、 汇 编 一 样 ， 写 完 基本 上 就 自己 能 看 届 ， 别 人 看 就 跟 看 天 书 一 样 ， 现 在 的 高 级 语 
言 ， 要 像 写 中 文 汉字 一 样 ， 你 写 的 ， 别 人 能 看 懂 。 这 就 是 建造 者 模式 。 


一 vv 


11.2 建造 着 模 式 的 定义 


建造 者 模式 (Builder Pattern) 也 叫做 生成 器 模式 ， 其 定义 如 下 : 


Separate the construction of a complex object from its representation 

so that the same construction process can create different representations. 

(将 一 个 复杂 对 象 的 构建 与 它 的 表示 分 离 ， 使 得 同样 的 构建 过 程 可 以 
创建 不 同 的 表示 。) 


建造 者 模式 的 通用 类 图 如 图 11-4 所 示 。 


二 BE。 = 


ConcreteBuilder 


图 11-4 建造 者 模式 通用 类 图 


在 建造 者 模式 中 ， 有 如 下 4 个 角色 : 


e@ Product 产 品类 


通常 是 实现 了 模板 方法 模式 ， 也 就 是 有 模板 方法 和 基本 方法 ， 
个 参考 第 10 章 的 模板 方法 模式 。 例 子 中 的 BenzModel 和 BMWModel 就 
属于 产品 类 。 


五 


e Builder 抽 象 建造 者 


规范 产品 的 组 建 ， 一 般 是 由 了 于 类 实现 。 例 子 中 的 CarBuilder 殉 属于 
抽象 建造 者 。 


e ConcreteBuilder 具 体 建造 者 


实现 抽象 类 定义 的 所 有 方法 ， 并 且 返 回 一 个 组 建 好 的 对 象 。 例 子 
中 的 BenzBuilder 和 BMWBuilder 束 属于 具体 建造 者 。 


e Director 导 演 类 


负责 安排 已 有 模块 的 顺序 ， 然 后 告诉 Builder 开 始 建造 ， 在 上 面 的 
例子 中 吏 是 我 们 的 老大 ，xx 公 司 找到 老大 ， 说 我 要 这 个 或 那个 类 型 的 
车 辆 模型 ， 然 后 老大 丈 把 命令 传递 给 我 ， 我 和 我 的 团队 就 开始 拼命 地 
建造 ， 于 是 一 个 项 目 建设 完毕 了 。 


建造 者 模式 的 通用 产 代码 也 比较 简单 ， 先 看 Product 类 ， 通 汕 它 钙 
一 个 组 合 或 继承 (如 模板 方法 模式 ) 产生 的 类 ， 如 代码 清单 11-12 所 


小 ° 


代码 清单 11-12 产品 类 


public class Product { 
public void doSomething()t{ 
// 独 立业 务 处 理 
} 


抽象 建造 者 如 代码 清单 11-13 所 示 。 


代码 清单 11-13 抽象 建造 者 


public abstract class Builder { 
// 设 置 产 品 的 不 同 部 分 ， 以 获得 不 同 的 产品 
public abstract void setPart(); 
// 建 造 产品 
public abstract Product buildProduct(); 


其 中 ，setPart 方 法 是 零件 的 配置 ， 什 么 是 零件 ? 其 他 的 对 象 ， 获 
得 一 个 不 同 零件 ， 或 者 不 同 的 闭 配 顺序 就 可 能 产生 不 同 的 产品 。 具 体 
的 建造 者 如 代码 清单 11-14 所 示 。 


代码 清单 11-14 具体 建造 者 


public class ConcreteProduct extends Builder { 
private Product product = new Product(); 
// 设 置 产品 零件 
public void setPart(){ 
/* 


* 产品 类 内 的 逻辑 处 理 
4 


} 

// 组 建 一 个 产品 

public Product buildProduct() { 
return product; 

} 


需要 注意 的 是 ， 如 果 有 多 个 产品 类 吏 有 儿 个 具体 的 建造 者 ， 而 且 
这 多 个 产品 类 具有 相同 接口 或 抽象 类 ， 参 考 我 们 上 面 的 例子 。 


导演 类 如 代码 清单 11-15 所 示 。 


代码 清单 11-15 导演 类 


public class Director { 
private Builder builder = new ConcreteProduct(); 
// 构 建 不 同 的 产品 
public Product getAProduct(){ 
builder.setPpart(); 
Dy i 
* 设置 不 同 的 零件 ， 产 生 不同 的 产品 
*/ 


return builder.buildProduct(); 


导演 类 起 到 封 逆 的 作用 ， 避 免 高 层 模块 深入 到 建造 者 内 部 的 实现 
类 。 当 然 ， 在 建造 者 模式 比较 庞大 时 ， 导 演 类 可 以 有 多 个 。 


11.3 建造 者 模式 的 应 用 
11.3.1 建造 者 模式 的 优点 


。 封 装 性 


使 用 建造 者 模式 可 以 使 客户 端 不 必 知 道 产品 内 部 组 成 的 细 闻 ， 如 
例子 中 我 们 就 不 需要 关心 每 一 个 具体 的 模型 内 部 是 如 何 实现 的 ， 产 生 
的 对 象 类 型 就 是 CarModel 。 


e 建造 者 独立 ， 容 易 扩 展 


BenzBuilder 和 BMWBuilder 是 相互 独立 的 ， 对 系统 的 扩展 非常 有 
利 。 


e 便于 控制 细 市 风险 
由 于 具体 的 建造 者 是 独立 的 ， 因 此 可 以 对 建造 过 程 逐步 细 化 ， 而 


不 对 其 他 的 模块 产生 任何 影响 。 


11.3.2 建造 者 模式 的 使 用 场景 


e 相同 的 方法 ， 不 同 的 执行 顺序 ， 产 生 不 同 的 事件 结果 时 ， 可 以 
采用 建造 者 模式 。 


。 多 个 部 件 或 零件 ， 都 可 以 装配 到 一 个 对 象 中 ， 但 是 产生 的 运行 
结果 又 不 相同 时 ， 则 可 以 使 用 该 模式 。 


e 广 品类 非常 复 淋 ， 或 者 产品 类 中 的 调用 顺序 不 同 产生 了 不 同 的 
效能 ， 这 个 时 候 使 用 建造 者 模式 非常 合适 。 


e 在 对 象 创建 过 程 中 会 使 用 到 系统 中 的 一 些 其 他 对 象 ， 这 些 对 和 象 
在 产品 对 象 的 创建 过 程 中 不 易 得 到 时 ， 也 可 以 采用 建造 者 模式 封闭 该 
对 象 的 创建 过 程 。 该 种 场景 只 能 是 一 个 补偿 方法 ， 因 为 一 个 对 象 不 容 
易 获 得 ， 而 在 设计 阶段 竟然 没有 发 觉 ， 而 要 通过 创建 者 模式 柔 化 创建 
过 程 ， 本 身 已 经 违反 设计 的 最 初 目 标 。 


11.3.3 建造 者 模式 的 注意 事项 


建造 者 模式 关注 的 是 零件 类 型 和 装配 工艺 (顺序 ，， 这 是 它 与 工 
三 方法 模式 最 大 不 同 的 地 方 ， 虽 然 同 为 创建 类 模式 ， 但 是 注重 点 不 
同 。 


11.4 建造 者 模式 的 扩展 


已 经 不 用 扩展 了 ， 因 为 我 们 在 汽车 模型 制造 的 例子 中 已 经 对 建造 
者 模式 进行 了 扩展 ， 引 入 了 模板 方法 模式 。 可 能 大 家 会 比较 疑惑 ， 为 
什么 在 其 他 介绍 设计 模式 的 书籍 上 创建 者 模式 并 不 是 这 样 说 的 ? 读者 
请 注意 ， 建 造 者 模式 中 还 有 一 个 角色 没有 说 明 ， 吏 是 零件 ， 建 造 者 怎 
么 去 建造 一 个 对 象 ? 是 零件 的 组 又， 组 逆 顺 序 不 同 对 象 效能 也 不 同 ， 
这 才 是 建造 者 模式 要 表达 的 核心 意义 ， 而 怎么 才能 更 好 地 达到 这 种 效 
条 呢 ? 引入 模板 方法 模式 是 一 个 非常 简单 而 有 效 的 办 法 。 


大 家 看 到 这 里 估计 束 开 始 犯 中 叶 了， 这 个 建造 者 模式 和 工 片 模式 
非常 相似 呀 ， 是 的 ， 非 常 相 似 ， 但 是 记 住 一 点 你 就 可 以 游 才 有 余地 使 
用 了 : 建造 者 模式 最 主要 的 功能 是 基本 方法 的 调用 顺序 安排 ， 也 束 是 
这 些 基本 方法 已 经 实现 了 ， 通 俗 地 说 就 是 零件 的 装配 ， 顺 序 不 同 产生 
的 对 象 也 不 同 ， 而 工厂 方法 则 重点 是 创建 ， 创 建 零件 是 它 的 主要 职 
责 ， 组 装 顺 序 则 不 是 它 关 心 的 。 


11.5 最 佳 实践 
再 次 说 明 ， 在 使 用 建造 者 模式 的 时 候 考虑 一 下 模板 方法 模式 ， 别 
孤立 地 思考 一 个 模式 ， 僵 化 地 套用 一 个 模式 会 让 你 受害 无 穷 


如 有 果 你 已 经 看 懂 本 书 举 的 例子 ， 并 认可 这 种 建造 者 模式 ， 那 你 束 
放心 使 用 ， 比 单独 使 用 建造 者 高 效 、 人 简洁 得 多 。 


第 12 章 ”代理 模式 


12.1 我 是 游戏 至 在 


2007 年 ， 感 觉 很 无 聊 ， 于 是 束 玩 了 一 段 时 间 的 网 络 游 戏 ， 游 戏 名 
就 不 说 了 ， 反 正 就 是 打 怪 、 升 级 、 砍 人 、 被 人 砍 ， 然 后 继续 打 怪 、 升 
级 、 打 怪 、 升 级 .…… 我 伦 了 两 个 月 的 时 间 升 到 80 级 ， 已 经 很 有 成 就 感 
了 ， 但 是 还 会 被 人 杀 死 ， 高 手 到 处 都 是 ，GM (Game Master， 游 戏 管 
理 员 ) 也 不 管 ， 对 于 咱 这 种 非 RMB 玩 家 基本 上 都 是 懒得 搭理 。 在 这 上 段 
时 间 我 是 体会 到 网 络 游戏 的 乐 与 苗 ， 参 与 家 族 (工会 ) 攻 城 ， 胜 利 后 
那 叫 一 个 乐 呀 ， 感 觉 自己 真是 一 个 “ 狂 骏 战士 "， 无 往 不 胜 ! 那 音 是 什 
么 呢 ? 就 是 升级 ， 为 了 升 一 级 ， 就 要 到 处 杀 怪 ， 做 任务 ， 那 个 游戏 还 
很 变态 ， 外 挂 管 得 很 严 ， 基 本 上 出 个 外 挂 ， 没 两 天 就 开始 封 账号 ， 不 
敢 用 ， 升 级 基本 上 都 要 靠 上 自己 手打 ， 累 呀 ! 我 曾经 的 记录 是 连 着 打 了 
23 个 小 时 ， 睡 觉 在 梦 中 还 和 大 BOSS 在 PK。 有 这 样 一 段 经 历 还 是 很 有 
意思 的 ， 作 为 架构 师 是 不 是 可 以 把 这 段 经 历 通过 架构 的 方式 记录 下 来 
呢 ? 当 然 可 以 了 ， 我 们 把 这 段 打 游戏 的 过 程 系 统 化 ， 非 常 简 单 的 一 个 
过 程 ， 如 图 12-1 所 示 。 


<<interface>> 


IGamePlayer 
+tlogm(String user, String password) 


Hvoid klIBoss() 
Hvoid uperade() 


Game Player 
[| 
EE 二 = 二 二 2J 


图 12-1 游戏 过 程 


太 简单 了 ， 定 义 一 个 接口 [GamePlayer， 是 所 有 喜爱 网 络 游戏 的 玩 
家 ， 然 后 定义 一 个 具体 的 实现 类 GamePlayer， 实 现 每 个 游戏 爱好 者 为 
了 玩 游戏 要 执行 的 功能 。 代 码 也 非常 简单 ， 我 们 先 来 看 IGamePlayer， 
如 代码 清单 12-1 所 示 。 


代码 清单 12-1 游戏 者 接口 


public interface IGamePlayer { 
// 登 录 游 戏 
public void login(String user,String password); 
// 杀 怪 ， 网 络 游戏 的 主要 特色 
public void killBoss(); 
// 升 级 
public void upgrade( ); 


非常 集 单 ， 定 义 了 三 个 方法 ， 分 别 是 我 们 在 网 络 游戏 中 最 常用 的 
功能 : 登录 游戏 、 杀 怪 和 升级 ， 其 实现 类 如 代码 清单 12-2 所 示 。 


代码 清单 12-2 游戏 者 


public class GamePlayer implements IGamePlayer { 
private String name = ""; 
// 通 过 构造 函数 传递 名 称 
public GamePlayer(String _name)t{ 
this.name = _name， 


} 

// 打 怪 ， 最 期 望 的 就 是 杀 老 怪 

public void killBoss() { 
System.out.printlin(this.name + "在 打 怪 ! ")， 


} 
// 进 游戏 之 前 你 肯定 要 登录 吧 ， 这 是 一 个 必要 条 件 
public void login(String user, String password) { 
System.out.println(" 登 录 名 为 "+user+" 的 用 
户 "+this.,name+" 登 录 成 功 ! "); 


} 

// 升 级 ， 升 级 有 很 多 方法 ， 花 钱 买 是 一 种 ， 做 任务 也 是 一 种 

public void upgrade() { 
System.out.printin(this.name + "又 升 了 一 级 ! "); 


在 实现 类 中 通过 构造 画 数 传递 进来 玩家 姓名 ， 方 便 进 行 后 期 的 调 
斌 工作。 我 们 通过 一 个 场景 类 来 模拟 这 样 的 游戏 过 程 ， 如 代码 清单 12- 
3 所 示 。 


代码 清单 12-3 场景 类 


public class Client { 
public static void main(String[|] args) { 

// 定 义 一 个 闯 迷 的 玩家 
IGamePlayer player = new GamePlayer(" 张 三"); 
// 开 始 打 游戏 ， 记 下 时 间 惟 
System,out,.printlLn(" 开 始 时 间 是 : 2009-8-25 10:45") 
player .Login("zhangSan"”， "password"); 
// 开 始 杀 怪 
player .killBoss(); 
// 升 级 
player .upgrade( ); 


// 记 杂 结 束 游 戏 时 间 
System,out.printlLn(" 结 束 时 间 是 : 2009-8-26 03:40"); 


程序 记录 了 游戏 的 开始 时 间 和 结束 时 间 ， 同 时 也 记录 了 在 游戏 过 
程 中 都 需要 做 什么 事情 ， 运 行 结果 如 下 : 


台 时 间 是 : 2009-8-25 10:45 


登录 名 为 zhangSan 的 用 户 张 三 登录 成 功 ! 


张 三 在 打 怪 | 


张 三 又 升 了 一 级 ! 


结束 时 间 是 : 2009-8-26 03:40 


运行 结 采 也 是 我 们 想 要 的 ， 记 录 我 这 段 时 间 的 网 游 生涯 。 心 理学 
家 告诉 我 们 ， 人 类 对 于 和音 难 的 记忆 比 对 喜悦 的 记忆 要 深刻 ， 但 是 人 类 
对 于 喜悦 是 “ 趋 利 ” 性 的 ， 每 个 人 都 想 Happy， 都 不 想 让 兰 难 靠近 ， 有 要 
想 获得 茸 福 ， 否 难 也 是 在 所 难免 的 ， 我 们 的 网 游 生涯 也 是 如 此 。 游 戏 
打 时 间 长 了 ， 腰 酸 表 痛 、 眼 睛 干 淮 、 手 臂 酸 麻 ， 等 等 ， 也 束 是 网 络 成 
瘾 绪 合 症 都 出 来 了 。 其 结 采 束 类 似 吃 了 那个 “一 日 并 命 表 ”,，“ 筋 脉 逆 
流 ， 胡 思 乱 想 ， 而 致 走火 入 魔 "。 那 怎么 办 呢 ? 我 们 想 玩 游戏 ， 但 又 不 
想 健 触 到 游戏 中 的 烦恼 ， 如 何 解决 呢 ? 有 办 法 ， 现 在 游戏 代 练 的 公司 
非常 多 ， 我 把 目 己 的 账号 交 给 代 练 人 员 ， 由 他 们 去 帮 有 我 升级 ， 去 打 
怪 ， 非 常 好 的 想法 ， 我 们 来 修改 一 下 类 图 ， 如 图 12-2 所 示 。 


<<mterface>> 
IGamePlayer 


Client tHogin(String user, String password) 
tvold killBoss() 
+vold upgrade() 


i 
/ 


GamePlayerProxy GamePlayer 
Es===== = 二 = = 


+CGamePlaycrProxy(IGamePlayer gamePlayer) +CGamePlayer(Strng name) 


" 


图 12-2 游戏 代 练 帮忙 打 怪 


在 类 图 中 增加 了 一 个 GamePlayerProxy 类 来 代表 游戏 代 练 者 ， 它 也 
不 能 有 作 商 的 方法 是， 游戏 代 练 者 也 是 手动 打 怪 呀 ， 因 此 同样 继承 
IGamePlayer 接 口 ， 其 实现 如 代码 清单 12-4 所 示 。 


代码 清单 12-4 代 练 者 


public class GamePlayerProxy implements IGamePlayer { 
private IGamePlayer gamePlayer = null; 
// 通 过 构造 函数 传递 要 对 谁 进行 代 练 
public GamePlayerProxy(IGamePlayer _gamePlayer){ 
this.gamePlayer = _gamePlayer; 


// 代 练 杀 怪 
public void killBoss() { 
this.gamePlayer .killBoss(); 


} 

// 代 练 登录 

public void login(String user, String password) { 
this.gamePlayer.1login(user, password); 


// 代 练 升级 
public void upgrade() { 
this.gamePlayer .upgrade( ); 


很 简单 ， 首 先 通 过 构造 画 数 说 明了 要 代 谁 打 怪 升 级 ， 然 后 通过 手动 
开始 代用 户 打 怪 、 升 级 。 场 景 类 Client 代 码 也 稍 作 改 动 ， 如 代码 清单 


12-5 所 示 。 


代码 清单 12-5 改进 后 的 场景 类 


public class Client { 

public static void main(String[] args) { 
// 定 义 一 个 痢 迷 的 玩家 
IGamePlayer player = new GamePlayer(" 张 三"); 
// 然 后 再 定义 一 个 代 练 者 
IGamePlayer proxy = new GamePlayerProxy(player); 
// 开 始 打 游戏 ， 记 下 时 间 惟 
System,out,.printlLn(" 开 始 时 间 是 : 2009-8-25 10:45") 
proxy.1login("zhangSan", "password"); 
// 开 始 杀 怪 
proxy.killBoss(); 
// 升 级 
proxy.upgrade( )， 
// 记 录 结 束 游戏 时 间 
System.out.println(" 结 束 时 间 是 : 2009-8-26 03:40"); 


ww 


运行 结果 也 完全 相同 ， 还 是 张 三 这 个 用 户 在 打 怪 ， 运 行 结果 如 


司 是 : 2009-8-25 10:45 


始 时 


登录 名 为 zhangSan 的 用 户 张 三 登录 成 功 ! 


张 三 在 打 怪 | 


张 三 又 升 了 一 级 ! 


结束 时 间 是 : 2009-8-26 03:40 


征 的 ， 没 有 任何 改变 ， 但 是 你 有 没有 发 党 ， 你 的 族 戏 已 经 在 升 
级 ， 有 人 在 帮 你 干 活 了 ! 终于 升级 到 120 级 ， 基 本 上 在 本 服务 区 ， 除 了 
GM 外 ， 这 个 你 可 蕉 不 起 ! 这 束 古 代理 模式 。 


12.2 代理 模式 的 定义 
代理 模式 (Proxy Pattern) 是 一 个 使 用 率 非常 高 的 模式 ， 其 定义 如 
下 : 


Provide a surrogate or placeholder for another object to control access 


to it，( 为 其 他 对 象 提供 一 种 代理 以 控制 对 这 个 对 象 的 访问 。) 


代理 模式 的 通用 类 图 如 图 12-3 所 示 。 


图 12-3 代理 模式 的 通用 类 图 


代理 模式 也 叫做 委托 模式 ， 它 是 一 项 基本 设计 技巧 。 许 多 其 他 的 
模式 ， 如 状态 模式 、 策 略 模式 、 访 问 者 模式 本 质 上 有 征 在 更 特殊 的 场合 
采用 了 委托 模式 ， 而 且 在 日 并 的 应 用 中 ， 代 理 模 式 可 以 提供 非常 好 的 


访问 控制 。 在 一 些 著名 开源 软件 中 也 经 常见 到 它 的 喘 影 ， 如 Struts2 的 
Form 元 素 映 射 就 采用 了 代理 模式 (准确 地 说 是 动态 代理 模式 ) 。 我 们 
先 看 一 下 类 图 中 的 三 个 角色 的 定义 : 


e Subject 抽 象 主题 角色 


抽象 主题 类 可 以 是 抽象 类 也 可 以 是 接口 ， 是 一 个 最 普通 的 业务 类 
型 定义 ， 无 特殊 要 求 。 


e RealSubject 有 具体 主题 角色 


也 叫做 被 委托 角色 、 被 代理 角色 。 它 才 是 揭 大 头 ， 走 业务 逻辑 的 
具体 执行 者 。 


e Proxy 代 理 主题 角色 


也 叫做 委托 类 、 代 理 类 。 它 负责 对 真实 角色 的 应 用 ， 把 所 有 抽 和 象 
主题 类 定义 的 方法 限制 委托 给 真实 主题 角色 实现 ， 并 且 在 真实 主题 角 
色 处 理 完毕 前 后 做 预 处理 和 善后 处 理工 作 。 


我 们 首先 来 看 Subject 抽 象 主题 类 的 通用 源码 ， 如 代码 清单 12-6 所 


代码 清单 12-6 抽象 主题 类 


public interface Subject { 
// 定 义 一 个 方法 


public void request(); 


在 接口 中 我 们 定义 了 一 个 方法 request 来 作为 方法 的 代表 ， 
RealSubject 对 它 进 行 实现 ， 如 代码 清单 12-7 所 示 。 


代码 清单 12-7 真实 主题 类 


public class RealSubject implements Subject { 
// 实 现 方 法 
public void request() { 
// 业 务 有 逻辑 处 理 
} 


RealSubject 古 一 个 正常 的 业务 实现 类 ， 代 理 模式 的 核心 束 在 代理 
类 上 ， 如 代码 清单 12-8 所 示 。 


代码 清单 12-8 代理 类 


public class Proxy implements Subject { 
// 要 代理 哪个 实现 类 
private Subject subject = null; 
// 默 认 被 代理 入 
public Proxy(){ 
this.subject = new Proxy(); 


} 
// 通 过 构造 函数 传递 代理 # 
public Proxy(Object...objects ){ 


} 

// 实 现 接 口中 定义 的 方法 

public void request() { 
this.beforel( ); 
this.subject.request(); 
this.after(); 


} 

// 预 处 理 

private void before(){ 
//do something 


} 

// 善 后 处 理 

private void after(){ 
//do something 

上 


看 到 这 里 ， 大 家 别 尺 讶 ， 为 什么 会 出 现 before 和 after 方 法 ， 继 续 看 
下 去 ， 这 是 一 个 “引子 ”， 能 够 引出 一 个 轨 新 的 编程 模式 。 


一 个 代理 类 可 以 代理 多 个 被 委托 者 或 被 代理 者 ， 因 此 一 个 代理 类 
具体 代理 哪个 真实 主题 角色 ， 是 由 场景 类 决定 的 。 当 然 ， 最 简单 的 情 
况 束 是 一 个 主题 类 和 一 个 代理 类 ， 这 是 最 简洁 的 代理 模式 。 在 通常 情 
况 下 ， 一 个 接口 只 需要 一 个 代理 类 吏 可 以 了 ， 有 具体 代理 哪个 实现 类 由 
高 层 模 块 来 决定 ， 也 天 是 在 代理 类 的 构造 男 数 中 传递 被 代理 者 ， 例 如 
我 们 可 以 在 代理 类 Proxy 中 增加 如 代码 清单 12-9 所 示 的 构造 画 数 。 


代码 清单 12-9 代理 的 构造 函数 


public Proxy(Subject _subject)t{ 
this.subject = _subject; 
} 


你 要 代理 谁 束 产生 该 代理 的 实例 ， 然 后 把 被 代理 者 传递 进来 ， 该 
模式 在 实际 的 项 目 应 用 中 比较 广泛 。 


12.3 代理 模式 的 应 用 
12.3.1 代理 模式 的 优点 


e 职责 清晰 


真实 的 角色 就 是 实现 实际 的 业务 逻辑 ， 不 用 关心 其 他 非 本 职责 的 
事务 ， 通 过 后 期 的 代理 完成 一 件 事务 ， 附 市 的 结果 束 是 编程 俏 话 清 
晰 。 

e 局 扩展 性 


具体 主题 角色 是 随时 都 会 发 生变 化 的 ， 只 要 它 实现 了 接口 ， 甫 管 
它 如 何 变化 ， 都 逃 不 脱 如 来 佛 的 手掌 (接口) ， 那 我 们 的 代理 类 完全 
忠 可 以 在 不 做 任何 修改 的 情况 下 使 用 。 


e 智能 化 


这 在 我 们 以 上 的 讲解 中 还 没有 体现 出 来 ， 不 过 在 我 们 以 下 的 动态 
代理 章 证 中 你 束 会 看 到 代理 的 智能 化 有 兴趣 的 读者 也 可 以 看 看 Struts 是 
如 何 把 表单 元 素 映 冉 到 对 象 上 的 。 


12.3.2 代理 模式 的 使 用 场景 


我 相信 第 一 次 接触 到 代理 模式 的 读者 肯定 很 俘 问 ， 为 什么 要 用 代 
理 呀 ? 想 想 现实 世界 吧 ， 打 官司 为 什么 要 找 个 律师 ?因为 你 不 想 参 与 
中 间 过 程 的 是 是 非 非 ， 只 要 完成 目 己 的 答辩 殉 成 ， 其 他 的 比如 事前 调 
但、 事后 追查 都 由 律师 来 搞定 ， 这 束 是 为 了 减轻 你 的 负担 。 代 理 模 式 
的 使 用 场景 非常 多 ， 大 家 可 以 看 看 Spring AOP， 这 是 一 个 非常 典型 的 
动态 代理 。 


12.4 代理 模式 的 扩展 
12.4.1 普通 代理 


在 网 络 上 代理 服务 器 设置 分 为 透明 代理 和 普通 代理 ， 是 什么 意思 
呢 ? 透明 代理 就 是 用 户 不 用 设置 代理 服务 器 地 址 ， 就 可 以 直接 访问 ， 也 
忠 古 说 代理 服务 器 对 用 户 来 说 是 透明 的 ， 不 用 知道 它 存 在 的 ， 普 通 代 理 
则 是 需要 用 户 自 己 设置 代理 服务 器 的 IP 地 址 ， 用 户 必 须知 道 代理 的 存 
在 。 我 们 设计 模式 中 的 普通 代理 和 强制 代理 也 是 类 似 的 一 种 结构 ， 普 通 
代理 束 是 我 们 要 知道 代理 的 存在 ， 也 束 古 类 似 的 GamePlayerProxy 这 个 类 
的 存在 ， 然 后 才能 访问 ， 强 制 代理 则 是 调用 者 直接 调用 真实 角色 ， 而 不 
用 关心 代理 是 否 存在 ， 其 代理 的 产生 是 由 真实 角色 决定 的 ， 这 样 的 解释 
还 是 比较 复 洒 ， 我 们 还 是 用 实例 来 讲解 。 


首先 说 普通 代理 ， 它 的 要 求 融 是 客户 端 只 能 访问 代理 角色 ， 而 不 能 
访问 真实 角色 ， 这 是 比较 简单 的 。 我 们 以 上 面 的 例子 作为 扩展 ， 我 自己 
作为 一 个 游戏 玩家 ， 我 肯定 自己 不 练 级 了 ， 也 就 是 场景 类 不 能 再 直接 
new 一 个 GamePlayer 对 象 了 ， 它 必须 由 GamePlayerProxy 来 进行 模拟 场 
景 ， 类 图 修改 如 图 12-4 所 示 。 


<<interface>> 
IGamePlayer 


+login(String user, String password) 
+void killBoss() 
+void uperade() 


Client . 
. GamePlayer 


| +GamePlayer (IGamePlayer gamePlayer, Strng name) 


GamePlayerProxy 


+GamePlayerProxy (String _name) 


图 12-4 普通 代理 类 图 


改动 很 小 ， 仪 仅 修 改 了 两 个 实现 类 的 构造 印 数 ，GamePlayer 的 构造 
函数 增加 了 _gamePlayer 参 数 ， 而 代理 角色 则 只 要 传 入 代理 者 名 字 即 可 ， 
而 不 需要 说 是 奉 哪 个 对 象 做 代理 。GamePlayer 类 如 代码 清单 12-10 所 示 。 


代码 清单 12-10 普通 代理 的 游戏 者 


public class GamePlayer implements IGamePlayer { 
private String name = ""; 
// 构 造 本 数 限制 谁 角 创建 对 象 ， 并 同时 传递 姓名 
public GamePlayer(IGamePlayer _gamePlayer,String _nanme) 
throws Exceptiont{ 
if(_gamePlayer == null ){ 
throw new Exception(" 不 能 创建 真实 角色 ! ")， 
}elsef 
this.name = _name， 
} 


} 

// 打 怪 ， 最 期 望 的 就 是 杀 老 怪 

public void killBoss() { 
System.out.println(this.name + "在 打 怪 ! "); 

} 


// 进 游戏 之 前 你 肯定 要 登录 吧 ， 这 是 一 个 必要 条 件 
public void login(String user, String password) { 
System.out. printin(" 登 录 名 为 "+user + "的 用 户 " + 
this.name + "登录 成 功 ! ")， 


// 升 级 ， 升 级 有 很 多 方法 ， 花 钱 买 是 一 种 ， 做 任务 也 是 一 和 
public void upgrade() { 

System.out.println(this.name + "又 升 了 一 级 ! "); 
} 


在 构造 函数 中 ， 传 递 进来 一 个 IGamePlayer 对 象 ， 检 查 谁 能 创建 真实 
的 角色 ， 当 然 还 可 以 有 其 他 的 限制 ， 比 如 类 名 必须 为 Proxy 类 等 ， 读 者 可 
以 根据 实际 情况 进行 扩展 。GamePlayerProxy 如 代码 清单 12-11 所 示 。 


代码 清单 12-11 普通 代理 的 代理 者 


public class GamePlayerProxy implements IGamePlayer { 
private IGamePlayer gamePlayer = null; 
// 通 过 构造 函数 传递 要 对 谁 进行 代 练 
public GamePlayerProxy(String name ){ 
try { 


gamePlayer = new GamePJlayer(this,name ) ， 
} catch (Exception e) { 

// TODO 异常 处 班 
} 


} 

// 代 练 杀 怪 

public void killBoss() { 
this.gamePlayer .killBoss( ); 


} 

// 代 练 登录 

public void login(String user, String password) { 
this.gamePlayer.login(user, password); 


} 

// 代 练 升级 

public void upgrade() { 
this.gamePlayer .upgrade( ); 

} 


FE 


仅仅 修改 了 构 千 函数 ， 传 递 进来 一 个 代理 者 名 称 ， 即 可 进行 代理 ， 
在 这 种 改造 下 ， 系 统 更 加 人 简 话 了 ， 调 用 者 只 知道 代理 存在 束 可 以 ， 不 用 
知道 代理 了 谁 。 同 时 场景 类 也 稍 作 改 动 ， 如 代码 清单 12-12 所 示 。 


代码 清单 12-12 普通 代理 的 场景 类 


public class Client { 

public static void main(String[] args) { 
// 然 后 再 定义 一 个 代 练 者 
IGamePlayer proxy = new GamePlayerProxy(" 张 三 " ) ， 
// 开 始 打 游 戏 ， 记 下 时 间 戳 
System.out,.printlLn(" 开 始 时 间 是 : 2009-8-25 10:45"); 
proxy.login("zhangSan", "password"); 
// 开 始 杀 怪 
proxy.killBoss(); 
// 升 级 
proxy.upgrade( ); 
// 记 录 结 束 游 戏 时 间 
System.out .printlin(" 结 束 时 间 是 : 2009-8-26 03:40"); 


上 


| 


运行 结果 完全 相同 。 在 该 模式 下 ， 调 用 者 只 知 代理 而 不 用 知道 真 
的 角色 是 谁 ， 屏 蔽 了 真实 角色 的 变更 对 高 层 模 块 的 有 影响， 真实 的 主题 角 
色 想 怎么 修改 就 怎么 修改 ， 对 高 层次 的 模块 没有 任何 的 影响 ， 只 要 你 实 
现 了 接口 所 对 应 的 方法 ， 该 模式 非 第 适合 对 扩展 性 要 来 较 高 的 场合 。 当 
然 ， 在 实际 的 项 目 中 ， 一 般 痢 是 通过 约定 来 茜 上 上 new 一 个 真实 的 角色 ， 
这 也 是 一 个 非常 好 的 方案 。 


注意 “普通 代理 模式 的 约束 问题 ， 尽 量 通 过 团队 内 的 编程 规范 类 约 
束 ， 因 为 每 一 个 主题 类 是 可 被 重用 的 和 可 维护 的 ， 使 用 技术 约束 的 方式 


对 系统 维护 是 一 种 非常 不 利 的 因素 。 


12.4.2 强制 代理 


强制 代理 在 设计 模式 中 比较 另类， 为 什么 这 么 说 呢 ? 一 般 的 思维 都 
征 通 过 代理 找到 真实 的 角色 ， 但 是 强制 代理 却 是 要 “强制 ”， 你 必须 通过 
真实 角色 得 找到 代理 角色 ， 人 否则 你 不 能 访问 。 有 下 管 你 是 通过 代理 类 还 是 
通过 直接 new 一 个 主题 角色 类 ， 都 不 能 访问 ， 只 有 通过 真实 角色 指定 的 
代理 类 才 可 以 访问 ， 也 束 是 说 由 真实 角色 管理 代理 角色 。 这 么 说 吧 ， 局 
层 模块 new 了 一 个 真实 角色 的 对 象 ， 返 回 的 却 是 代理 角色 ， 这 束 好 比 是 
你 和 一 个 明星 比较 熟 ， 相 互 认识 ， 有 件 事 情 你 需要 回 她 确认 一 下 ， 于 是 
你 束 直 接 拨 通 了 明星 的 电话 : 


“ 喂 ， 沙 比 蚜 ， 我 要 见 一 下 xxx 导 演 ， 你 帮 下 忙 了 ! ” 


“不 行 蚜 惨 哥 ， 我 这 几 天 很 忙 蚜 ， 你 找 我 的 经 纪 人 了 吧 .….…… 


郁 癌 了 吧 ， 你 是 想 直 接 绕 过 她 的 代理 ， 谁 知道 返回 的 还 是 她 的 代 
理 ， 这 就 是 强制 代理 ， 你 可 以 不 用 知道 代理 存在 ， 但 是 你 的 所 作 所 为 还 
是 需要 代理 为 你 提供 。 我 们 把 上 面 的 例子 稍 作 修 改 就 可 以 完成 ， 如 图 12- 
5 所 示 。 


<<interface>> 
ICamePlayer 


| 
- +login(String user, String password) 
Client +void killBoss() 
+void upgrade() 
+GamePlayer getProxy() 


GamePlayerProxy 
| 


+GamePlayerProxy(IGamePlayer gamePlayer) 


图 12-5 强制 代理 类 图 


在 接口 上 增加 了 一 个 getProxy 方 法 ， 真 实 和 角色 GamePlayer 可 以 指定 
一 个 目 己 的 代理 ,除了 代理 外 谁 都 不 能 访问 。 我 们 来 看 代码 ， 先 看 
IGamePlayer 接 口 ， 如 代码 清单 12-13 所 示 。 


代码 清单 12-13 强制 代理 的 接口 类 


public interface IGamePlayer { 
// 登 录 游 戏 
public void login(String user,String password); 
// 杀 怪 ， 这 是 网 络 游戏 的 主要 特色 
public void killBoss(); 
// 升 级 
public void upgrade( ); 
// 每 个 人 都 可 以 找 一 下 自己 的 代理 
public IGamePlayer getProxy(); 


仅仅 增加 了 一 个 getProxy 方 法 ， 指 定 要 访问 目 己 必须 通过 哪个 代 
理 ， 实 现 类 也 要 做 适当 的 修改 ， 先 看 真实 角色 GamePlayer， 如 代码 清单 


12-14 所 示 。 


代码 清单 12-14 强制 代理 的 真实 角色 


public class GamePlayer implements IGamePlayer { 
private String name = ""， 
// 我 的 代理 是 谁 
private IGamePlayer proxy = null; 
public GamePlayer(String _name)t{ 
this.name = _name; 


} 
// 找 到 自己 的 代理 
public IGamePlayer getProxy(){ 
this.proxy = new GamePlayerProxy(this); 
return this.proxy; 


} 
// 打 怪 ， 最 期 望 的 就 是 杀 老 怪 
public void killBoss() { 
if(this,.isPproxy())t{ 
System.out.println(this.name + "在 打 怪 ! "); 


}+elset 


System.out .println(" 请 使 用 指定 的 代理 访问 " ) ; 


} 
// 进 游戏 之 前 你 肯定 要 登录 吧 ， 这 是 一 个 必要 条 件 
public void login(String user, String password) { 
if(this.isPproxy())t{ 
System.out .println(" 登 录 名 为 "+user+" 的 用 
户 "+this .name+" 登 录 成 功 !")， 
}elsef{ 


System.out .println(" 请 使 用 指定 的 代理 访问 " ) ; ; 
} 


} 
// 升 级 ， 升 级 有 很 多 方法 ， 花 钱 买 是 一 种 ， 做 任务 也 是 一 和 
public void upgrade() { 
if(this.isPproxy())t{ 
System.out.printin(this.name + " 又 升 了 一 


级 !"); 
}elsef{ 


} 


// 校 验 是 否 是 代理 访问 
private boolean isProxy()t{ 
if(this.proxy == null)t{ 
return false; 


System.out.println(" 请 使 用 指定 的 代理 访问 " ) ; 


}+elset 


} 


return true,; 


增加 了 一 个 私有 方法 ， 检 查 是 人 否 是 目 己 指 定 的 代理 ， 是 指定 的 代理 


则 允许 访问 ， 否 则 不 允许 访问 。 我 们 再 来 看 代理 角色 ， 如 代码 清单 12-15 
所 示 。 


代码 清单 12-15 强制 代理 的 代理 类 


public class GamePlayerProxy implements IGamePlayer { 


private Loaner Cae gamePlayer = null; 


// 构 造 画 数 传递 用 户 

public GamePlayerProxy(IGamePlayer _gamePlayer)t{ 
this.gamePlayer = _gamePlayer; 

} 

// 代 练 杀 怪 


public void killBoss() { 
this.gamePlayer .killBoss( ); 


} 

// 代 练 登录 

public void login(String user, String password) { 
this.gamePlayer.login(user, password); 


} 

// 代 练 升级 

public void upgrade() { 
this.gamePlayer .upgrade( ); 


} 

// 代 理 的 代理 暂时 还 没有 ， 就 是 自己 

public IGamePlayer getProxy(){ 
return this,; 

} 


代理 角色 也 可 以 再 次 被 代理 ， 这 里 我 们 整 没 有 继续 延伸 下 去 了 ， 查 


找 代 理 的 方法 就 返回 目 己 的 实例 。 代 码 部 写 完 毕 了 ， 我 们 先 按照 前 规 的 
思路 来 运行 一 下 ， 直 接 new 一 个 真实 角色 ， 如 代码 清单 12-16 所 示 。 


代码 请 单 12-16 直接 访问 真实 角色 


public class Client { 
public static void main(String[] args) { 


// 定 义 一 个 游戏 的 角色 


下 


IGamePlayer player = new GamePlayer(" 张 三 " ) ; 

// 开 始 打 游 戏 ， 记 下 时 间 戳 

System.out .printlin(" 开 始 时 间 是 : 2009-8-25 10:45"); 
player.1login("zhangSan", "password"); 


// 开 始 杀 怪 


player .killBoss(); 

// 升 级 

player .upgrade( ); 

// 记 录 结 束 游戏 时 间 

System.out .printlin(" 结 束 时 间 是 : 2009-8-26 03:40"); 


想 想 看 能 运行 吗 ? 运行 结果 如 下 所 示 : 


开始 时 间 是 : 2009-8-25 10:45 


请 使 用 指定 的 代 到 


访问 


请 使 用 指定 的 代 到 


访问 


请 使 用 指定 的 代 到 


访问 


结束 时 间 是 : 2009-8-26 03:40 


它 要 求 你 必须 通过 代理 来 访问 ， 你 想 要 直接 访问 它 ，1] 儿 部 没有 ， 
好 ， 你 要 我 通过 代理 来 访问 ， 那 整 生 产 一 个 代理 ， 如 代码 清单 12-17 所 


修 ° 


代码 清单 12-17 直接 访问 代理 类 


public class Client { 
public static void main(String[] args) { 


// 定 义 一 个 游戏 的 角色 


下 


IGamePlayer player = new GamePlayer(" 张 三 " ) ; 
// 然 后 再 定义 一 个 代 练 者 
IGamePlayer proxy = new GamePlayerProxy(player); 
// 开 始 打 游戏 ， 记 下 时 间 惟 

System.out .printlin(" 开 始 时 间 是 : 2009-8-25 10:45"); 
proxy.login("zhangSan", "password"); 

// 开 始 杀 怪 
proxy.killBoss( ); 

// 升 级 

proxy.upgrade( ); 

// 记 录 结 束 游戏 时 间 

System,.out,.println(" 结 束 时 间 是 : 2009-8-26 03:40"); 


这 次 能 访问 吗 ? 还 是 不 行 ， 结 果 如 下 所 示 : 


开始 时 间 是 : 2009-8-25 10:45 


请 使 用 指定 的 代理 访问 


请 使 用 指定 的 代理 访问 


请 使 用 指定 的 代理 访问 


结束 时 间 是 : 2009-8-26 03:40 


还 是 不 能 访问 ， 为 什么 呢 ? 它 不 是 真实 角色 指定 的 对 象 ， 这 个 代理 
对 象 是 你 目 己 new 出 来 的 ， 当 然 真 实 对 和 象 不 认 了 ， 这 束 好 比 是 那个 明 
星 ， 人 家 已 经 告诉 你 去 找 她 的 代理 人 了 ， 你 随便 找 个 代理 人 能 成 吗 ? 你 
必须 去 找 她 指定 的 代理 才 成 ! 我 们 修改 一 下 场景 类 ， 如 代码 清单 12-18 所 


人 小? 


代码 清单 12-18 强制 代理 的 场景 类 


public class Client { 
public static void main(String[] args) { 


// 定 义 一 个 游戏 的 角色 


下 


IGamePlayer player = new GamePlayer(" 张 三 ") ; 


// 获 得 指定 的 代理 


IGamePlayer proxy = player.getProxy() ; 


// 开 


全 打 游 戏 ， 记 下 时 间 截 


System.out .printlin(" 开 始 时 间 是 : 2009-8-25 10:45"); 
proxy.login("zhangSan", "password"); 


// 开 


台 杀 怪 


proxy.killBoss( ) ， 

// 升 级 

proxy.upgrade( ); 

// 记 录 结 束 游 戏 时 间 

System.out .printlin( "结束 时 间 是 : 2009-8-26 03:40"); 


| 


运行 结果 如 下 : 


开始 时 间 是 : 2009-8-25 10:45 


登录 名 为 zhangSan 的 用 户 张 三 登 录 成 功 ! 


张 三 在 打 怪 ! 


张 三 又 升 了 一 级 ! 


AS 


吉 束 时 间 是 : 2009-8-26 03:40 


OK， 可 以 正常 访问 代理 了 。 强 制 代理 的 概念 就 是 要 从 真实 角色 查找 
到 代理 角色 ， 不 允许 直接 访问 真实 角色 。 高 层 模 块 只 要 调用 getProxy 整 
可 以 访问 真实 角色 的 所 有 方法 ， 它 根本 束 不 需要 产生 一 个 代理 出 来 ， 代 
理 的 管理 已 经 由 真实 角色 目 己 完成 。 


12.4.3 代理 是 有 个 性 的 


一 个 类 可 以 实现 多 个 接口 ， 完 成 不 同 任务 的 整合 。 也 束 古 说 代理 类 
不 仅仅 可 以 实现 主题 接口 ， 也 可 以 实现 其 他 接口 完成 不 同 的 任务 ， 而 且 


代理 的 目的 是 在 目标 对 象 方法 的 基础 上 作 增 强 ， 这 种 增强 的 本 质 通常 就 
征 对 目标 对 象 的 方法 进行 拦截 和 过 滤 。 例 如 游戏 代理 是 需要 收费 的 ， 升 
一 级 需要 5 元 钱 ， 这 个 计算 功能 就 是 代理 类 的 个 性 ， 它 应 该 在 代理 的 接口 
中 定义 ， 如 图 12-6 所 示 。 


<<Interface>> 
ICamePlayer 
TENEEREEES3 


Hlogin(String user, String password) 


- +void killBoss() 
+void count() +void upegrade() 


Game PlayerProxy 


| 
+GamePlayerProxy(IGamePlayer gamePlayer) 


Client 
| 


图 12-6 代理 类 的 个 性 


增加 了 一 个 IProxy 接 口 ， 其 作用 是 计算 代理 的 费用 。 我 们 先 来 看 
IProxy 接 口 ， 如 代码 清单 12-19 所 示 。 


代码 清单 12-19 代理 类 的 接口 


public interface IProxy { 
// 计 算 费 用 
public void count(); 


仅仅 一 个 方法 ， 非 党 简单 ， 看 GamePlayerProxy 市 来 的 变化 ， 如 代码 
清单 12-20 所 示 。 


代码 清单 12-20 代理 类 


public class GamePlayerProxy implements IGamePlayer,IProxy { 
private IGamePlayer gamePlayer = null; 
// 通 过 构造 范 数 传递 要 对 谁 进行 代 练 
public GamePlayerProxy(IGamePlayer _gamePlayer)t{ 
this.gamePlayer = _gamePlayer; 


} 

// 代 练 杀 怪 

public void killBoss() { 
this.gamePlayer .killBoss( ); 


} 

// 代 练 登录 

public void login(String user, String password) { 
this.gamePlayer.login(user, password); 


} 

// 代 练 升级 

public void upgrade() { 
this.gamePlayer .upgrade( ); 
this.count(); 


} 
// 计 算 费 用 
public void count()t{ 

System.out.println(" 升 级 总 费用 是 : 150 元 " ) ; 
} 


实现 了 IProxy 接 口 ， 同 时 在 upgrade 方 法 中 调用 该 方法 ， 完 成 费用 结 
算 ， 其 他 的 类 都 没有 任何 改动 ， 运 行 结 果 如 下 : 


开始 时 间 是 : 2009-8-25 10:45 


登录 名 为 zhangSan 的 用 户 张 三 登 录 成 功 ! 


张 三 在 打 怪 | 


张 三 又 升 了 一 级 ! 


结束 时 间 是 : 2009-8-26 03:40 


好 了 ， 代 理 公 司 也 赚钱 了 ， 我 的 游戏 也 升级 了 ， 宵 大 欢喜 。 代 理 类 
不 仅仅 是 可 以 有 目 己 的 运算 方法 ， 通 党 的 情况 下 代理 的 职 贡 并 不 一 定单 
一 ， 它 可 以 组 合 其 他 的 真实 角色 ， 也 可 以 实现 目 己 的 职责 ， 比 如 计算 费 
用 。 代 理 类 可 以 为 真实 角色 预 处 理 消 肯 、 过 滤 消 忌 、 消 忆 转 发、 事后 处 
理 消 轧 等 功能 。 当 然 一 个 代理 类 ， 可 以 代理 多 个 真实 角色 ， 并 且 真 实 角 
色 之 间 可 以 有 类 合 关系 ， 读 者 可 以 目 行 扩展 一 下 。 


12.4.4 动态 代理 


放 在 最 后 讲 的 一 般 都 是 压轴 大 戏 ， 动 态 代 理 就 是 如 此 ， 上 面 的 章节 
都 是 一 个 引子 ， 动 态 代理 才 是 重头 戏 。 什 么 是 动态 代理 ? 动态 代理 是 在 
实现 阶段 不 用 关心 代理 谁 ， 而 在 运行 阶段 才 指 定 代理 哪 一 个 对 象 。 相 对 
来 说 ， 目 己 写 代理 类 的 方式 就 是 静态 代理 。 本 章节 的 核心 部 分 就 在 动态 
代理 上 ， 现 在 有 一 个 非常 流行 的 名 称 叫做 面 癌 横 切 面 编程 ， 也 束 定 AOP 
(Aspect Oriented Programming) ， 其 核心 就 是 采用 了 动态 代理 机 制 ， 既 
然 这 么 重要 ， 我 们 束 来 看 看 动态 代理 是 如 何 实现 的 ， 还 古 以 打 游 戏 为 
例 ， 类 图 修改 一 下 以 实现 动态 代理 ， 如 图 12-7 所 示 。 


<<mterface>> 
ICamePlayer 
| 
+void login(String user, String password) 


<<Interface>> 


JnvocationHandler 


+void killBoss() 
+void upgrade() 


Game PlaylH 


GamePlayer 


图 12-7 动态 代理 


在 类 图 中 增加 了 一 个 InvocationHandler 接 口 和 GamePlayIH 类 ， 作 用 
就 是 产生 一 个 对 象 的 代理 对 象 ， 其 中 InvocationHandler 是 JDK 提 供 的 动态 
代理 接口 ， 对 被 代理 类 的 方法 进行 代理 。 我 们 来 看 程序 ， 接 口 保持 不 
变 ， 实 现 类 也 没有 变化 ， 请 参考 代码 清单 12-1 和 代码 清单 12-2 所 示 。 我 
们 来 看 DynamicProxy 类 ， 如 代码 清单 12-21 所 示 。 


代码 清单 12-21 动态 代理 类 


public class GamePlayIH implements InvocationHandler { 
// 被 代理 者 
Class cls =null; 
// 被 代理 的 实例 
Object obj = null; 
// 我 要 代理 谁 
public GamePlayIH(Object _obj)t{ 
this.obj = _obj; 
} 


// 调 用 被 代理 的 方法 
public Object invoke(Object proxy, Method method, Object[] 
args) 


throws Throwable { 
Object result = method.invoke(this.ob]j, args); 
return result; 


其 中 invoke 方 法 是 接口 InvocationHandler 定 义 必须 实现 的 ， 它 完成 对 
真实 方法 的 调用 。 我 们 来 详细 讲解 一 下 InvocationHandler 接 口 ， 动 态 代 理 
是 根据 被 代理 的 接口 生成 所 有 的 方法 ， 也 就 是 说 给 定 一 个 接口 ， 动 态 代 

宣称 “我 已 经 实现 该 接口 下 的 所 有 方法 了 ”， 那 各 位 读者 想 想 看 ， 动 
态 代理 怎么 才能 实现 被 代理 接口 中 的 方法 呢 ? 默认 情况 下 所 有 的 方法 返 
回 值 都 是 空 的 ， 是 的 ， 代 理 已 经 实现 它 了 ， 但 是 没有 任何 的 逻辑 含 
那 怎么 办 ? 好 办 ， 通 过 InvocationHandler 接 口 ， 所 有 方法 都 由 该 Handler 
来 进行 处 理 ， 即 所 有 被 代理 的 方法 都 由 InvocationHandler 接 管 实际 的 处 理 


任务 。 


我 们 接 下 来 看 看 场景 类 ， 如 代码 清单 12-22 所 示 。 


代码 清单 12-22 动态 代理 的 场景 类 


public class Client { 
public static void main(String[] args) throws Throwable 二 

// 定 义 一 个 痴迷 的 玩家 
IGamePlayer player = new GamePlayer(" 张 三 "); 
// 定 义 一 个 handler 
InvocationHandler handler = new GamePlayIH(player); 
// 开 始 打 游 戏 ， 记 下 时 间 惟 
System.out .printlin(" 开 始 时 间 是 : 2009-8-25 10:45"); 
// 获 得 类 的 class loader 
ClassLoader cl = player.getClass().getclassLoader(); 
// 动 态 产 生 一 个 代理 者 
IGamePlayer proxy = 


(IGamePlayer )Proxy.newProxyInstance(cl,new Class [ 
{IGamePlayer .class},handler )， 
// 登 录 
proxy.login("zhangSan", "password"); 
// 开 始 杀 怪 
proxy.killBoss(); 
// 升 级 
proxy,upgrade(); 
// 记 录 结 束 游 戏 时 间 
System.out.println( "结束 时 间 是 : 2009-8-26 03:40" ); 


很 奇怪 是 吗 ? 不 要 着 急 ， 继 续 看 下 去 。 其 运行 结 来 如 下 : 


开始 时 间 是 : 2009-8-25 10:45 


登录 名 为 zhangSan 的 用 户 张 三 登 录 成 功 ! 


张 三 在 打 怪 


张 三 又 升 了 一 级 ! 


NVS 


吉 束 时 间 是 : 2009-8-26 03:40 


我 们 还 是 让 代 练 者 帮 我 们 打 游 戏 ， 但 是 我 们 既 没 有 创建 代理 类 ， 也 
没有 实现 IGamePlayer 接 口 ， 这 瓯 是 动态 代理 。 别 急 ， 动 态 代理 可 不 仅仅 
就 这 么 多 内 容 ， 还 有 更 重要 的 ， 如 果 想 让 游戏 登录 后 发 一 个 信息 给 我 
们 ， 防 止 账号 被 人 盗用 嘛 ， 该 怎么 处 理 ? 直接 修改 被 代理 类 
GamePlayer? 这 不 是 一 个 好 办 法 ， 好 办 法 如 代码 清单 12-23 所 示 。 


代码 清单 12-23 修正 后 的 动态 代理 


public class GamePlayIH implements InvocationHandler { 
// 被 代理 者 
Class cls =null; 
// 被 代理 的 实例 
Object obj = null; 


// 我 要 代理 谁 
public GamePlayIH(Object _obj)t{ 
this.obj = _obj; 


} 

// 调 用 被 代理 的 方法 

public Object invoke(Object proxy, Method method, Object[] 
args) 


throws Throwable { 
Object result = method.invoke(this.obj, args); 
// 如 果 是 登录 方法 ， 则 发 送信 息 
if(method.getName().equalsIgnoreCase("1login"))t{ 
System.out.println(" 有 人 在 用 我 的 账号 登录 ! "); 


return result,; 


只 要 在 代理 中 增加 一 个 判断 吏 可 以 决定 是 否 要 发 送信 和 已， 运行 结 采 
如 下 : 


开始 时 间 是 : 2009-8-25 10:45 


登录 名 为 zhangSan 的 用 户 ” 张 三 登录 成 功 ! 
有 人 在 用 我 的 账号 登录 ! 


张 三 在 打 怪 ! 
张 三 又 升 了 一 级 ! 


NVS 


吉 束 时 间 是 : 2009-8-26 03:40 


太 棒 了 ! 有 人 用 我 的 账号 就 发 送 一 个 信息 ， 然 后 看 看 目 己 的 账号 是 
不 是 被 人 盗 了 ， 非 第 好 的 方法 ， 这 束 是 AOP 编 程 。AOP 编 程 没 有 使 用 什 
么 新 的 技术 ， 但 是 它 对 我 们 的 设计 、 编 码 有 非常 大 的 影响 ， 对 于 日 志 、 
事务 、 权 限 等 都 可 以 在 系统 设计 阶段 不 用 考虑 ， 而 在 设计 后 通过 AOP 的 
方式 切 过 去 。 既 然 动 态 代 理 是 如 此 诱 人 ， 我 们 来 看 看 通用 动态 代理 模 
型 ， 类 图 如 图 12-8 所 示 。 


DynamicProxy Client 
<<mterface>> <<mterface>> <<interface>> 
IAdvice InvocationHandler Subject 
BE = < 二 j 


Yo a 、 ~ Devendrice MyInvocationHandler RealSubject 
前 置 通知 各 一 


图 12-8 动态 代理 通用 类 图 


Fvoid exec() 


很 侧 单 ， 两 条 独立 发 展 的 线路 。 动 态 代 理 实现 代理 的 职责 ， 业 务 远 
辑 Subject 实 现 相关 的 逻辑 功能 ， 两 兰 之 间 没 有 必然 的 相互 硝 合 的 关系 。 
通知 Advice 从 另 一 个 切面 切入 ， 节 终 在 高 层 模块 也 就 是 Client 进 行 耦合 ， 
完成 逻辑 的 封装 任务 。 我 们 先 来 看 Subject 接 口 ， 如 代码 清单 12-24 所 示 。 


代码 清单 12-24 抽象 主题 


public interface Subject { 
// 业 务 操作 
public void doSomething(String str); 


其 中 的 doSomething 是 一 种 标识 方法 ， 可 以 有 多 个 逻辑 处 理 方 法 ， 实 
现 类 如 代码 清单 12-25 所 示 。 


代码 清单 12-25 真实 主题 


public class RealSubject implements Subject { 
// 业 务 操作 
public void doSomething(String str) { 
System.out.printlin("do something!---->" + str); 
} 


重点 是 我 们 的 MyInvocationHandler， 如 代码 清单 12-26 所 示 。 


代码 清单 12-26 动态 代理 的 Handler 类 


public class MyInvocationHandler implements InvocationHandler { 
// 被 代理 的 对 象 
private Object target = null; 
// 通 过 构造 函数 传递 一 个 对 象 
public MyInvocationHandler (Object _obj)t{ 
this.target = _obj; 


} 

// 代 理 方 法 

public Object invoke(Object proxy, Method method, Object[] 
args) 


throws Throwable { 
// 执 行 被 代理 的 方法 


return method.invoke(this.target, args); 


非常 简单 ， 所 有 通过 动态 代理 实现 的 方法 全 部 通过 invoke 方 法 调 
用 。DynamicProxy 代 码 如 代码 清单 12-27 所 示 。 


代码 清单 12-27 动态 代理 类 


public class DynamicProxy<T> { 
public static <T> T newProxyInstance(ClassLoader loader, 
Class<?>[] interfaces, InvocationHandler h)t 
// 寻 找 JoinPoint 连 接点 ，AOP 框 架 使 用 元 数据 定义 
if(true)t 
// 执 行 一 个 前 置 通知 
(new BeforeAdvice()).exec(); 


} 
// 执 行 目 标 ， 并 返回 结果 
return (T)Proxy.newProxyInstance(loader,interfaces, 


h) 


在 这 里 插入 了 较 多 的 AOP 术 语 ， 如 在 什么 地 方 (连接 点 ) 执行 什么 
行为 (通知 ) 。 我 们 在 这 里 实现 了 一 个 简单 的 横 切 面 编程 ， 有 经 验 的 读 
者 可 以 看 看 AOP 的 配置 文件 就 会 明白 这 段 代 码 的 意义 了 。 我 们 来 看 通知 
Advice， 也 融和 是 我 们 要 切入 的 类 ， 接 口 和 实现 如 代码 清单 12-28 所 示 。 


代码 清单 12-28 通知 接口 及 实现 


public interface IAdvice { 
// 通 知 只 有 一 个 方法 ， 执 行 即 可 
public void exec( ) ; 


public class BeforeAdvice implements IAdvicet{ 
public void exec(){ 
System.out .println(" 我 是 前 置 通知 ， 我 被 执行 了 ! ") ; 
} 


最 后 束 是 看 我 们 怎么 调用 了 ， 如 代码 清单 12-29 所 示 。 


代码 清单 12-29 动态 代理 的 场景 类 


public class Client { 
public static void main(String[] args) { 
// 定 义 一 个 主题 
Subject subject = new RealSubject(); 
// 定 义 一 个 Handler 
InvocationHandler handler = new 
MyInvocationHandler(subject); 
// 定 义 主题 的 代理 
Subject proxy = 
DynamicProxy.newProxyInstance(subject.getClass(). 
getClassLoader(), 
subject.getCclass().getIinterfaces(),handler); 
// 代 理 的 行为 


proxy.doSsomething("Finish"); 


| 


运行 结 采 如 下 所 示 : 


我 是 前 置 通知 ， 我 被 执行 了 ! 


do something!---->Finish 


好 ， 所 有 的 程序 都 看 完了 ， 我 们 回 过 头 来 看 看 程序 是 怎么 实现 的 。 
在 DynamicProxy 类 中 ， 我 们 有 这 样 的 方法 : 


this.obj=Proxy.newProxyInstance(c.getClassLoader(),c.getInterfaces(),new 


MyInvocationHandler(_obj)); 


该 方法 是 重新 生成 了 一 个 对 象 ， 为 什么 要 重新 生成 ? 你 要 使 用 代理 
呀 ， 注 意 c.getInterfaces0O 这 人 句 话 ， 这 是 非常 有 意思 的 一 句 话 ， 是 说 查找 到 
该 类 的 所 有 接口 ， 然 后 实现 接口 的 所 有 方法 。 当 然 了 ， 方 法 都 是 空 的 ， 
由 谁 具 体 负责 接管 呢 ? 是 new MyInvocationHandler(_Obj) 这 个 对 象 。 于 是 
我 们 知道 一 个 类 的 动态 代理 类 是 这 样 的 一 个 类 ， 由 InvocationHandler 的 实 
现 类 实现 所 有 的 方法 ， 由 其 invoke 方 法 接管 所 有 方法 的 实现 ， 其 动态 调 
用 过 程 如 图 12-9 所 示 。 


Client DynamicProxy MyInvocationHandler Subject 对 象 


doSomething() invoke() “invoke()™ 
一 一 一 一 -区 一 一 一 一 下 一 一 一 一 个 


图 12-9 动态 代理 调用 过 程 示意 图 


读者 可 能 注意 到 我 们 以 上 的 代码 还 有 更 进一步 的 扩展 余地 ， 注 意 
DynamicProxy 类 ， 它 是 一 个 通用 类 ， 不 具有 业务 意义 ， 如 果 我 们 再 产生 
一 个 实现 类 是 不 是 就 很 有 意义 了 呢 ? 如 代码 清单 12-30 所 示 。 


代码 清单 12-30 具体 业务 的 动态 代理 


public class SubjectDynamicProxy extends DynamicProxyt{ 
public static <T> T newProxyInstance(Subject subject)t 
// 获 得 classLoader 
ClassLoader loader = 
subject.getcCclass().getclassLoader(); 
// 获 得 接口 数组 
Class<?>[] classes = 
Subject.getClass().getInterfaceSs( ); 
// 获 得 handler 
InvocationHandler handler = new 
MyInvocationHandler(subject); 
return newProxyInstance(loader, classes, handler); 
} 


如 此 扩展 以 后 ， 高 层 模块 对 代理 的 访问 会 更 加 简单 ， 如 代码 清单 12- 
31 所 示 。 


代码 清单 12-31 场景 类 


public class Client { 
public static void main(String[] args) { 

// 定 义 一 个 主题 
Subject subject = new RealSubject(); 
// 定 义 主题 的 代理 
Subject proxy = 

SubjectDynamicProxy.newProxyInstance(Subject ) ; 
// 代 理 的 行为 
proxy.doSsomething("Finish"); 


[| 


征 不 是 更 加 商 单 了 ? 可 能 读者 束 要 提问 了 ， 这 样 与 静态 代理 还 有 什 
么 区 别 ? 都 是 需要 实现 一 个 代理 类 ， 有 区 别 ， 注 意 看 父 类 ， 动 态 代 理 的 
主要 意图 束 生 解决 我 们 第 说 的 “审计 ?问题 ， 也 束 是 横 切 面 编程 ， 在 不 改 
变 我 们 已 有 代码 结构 的 情况 下 增强 或 控制 对 象 的 行为 。 


注意 ”要 实现 动态 代理 的 前 要 条 件 是 : 被 代理 类 必须 实现 一 个 接 
口 ， 回 想 一 下 前 面 的 分 析 吧 。 当 然 了 ， 现 在 也 有 很 多 技术 如 CGLIB 可 以 
实现 不 需要 接口 也 可 以 实现 动态 代理 的 方式 。 


再 次 说 明 ， 以 上 的 动态 代理 是 一 个 通用 代理 框架 。 如 琳 你 想 设 计 晶 
己 的 AOP 框 架 ， 完 全 可 以 在 此 基础 上 扩展 ， 我 们 设计 的 是 一 个 通用 代 
理 ， 只 要 有 一 个 接口 ， 一 个 实现 类 ， 丈 可 以 使 用 该 代理 ， 完 成 代理 的 所 
有 功效 。 


12.5 最 佳 实践 


代理 模式 应 用 得 非常 广泛 ， 大 到 一 个 系统 框架 、 企 业 平台 ， 小 到 
代码 片段 、 事 务 处 理 ， 稍 不 留意 就 用 到 代理 模式 。 可 能 该 模式 是 大 家 
接触 最 多 的 模式 ， 而 且 有 了 AOP 大 家 写 代理 就 更 加 简单 了 ， 有 类 似 
Spring AOP 和 AspectJ 这 样 非常 优秀 的 工具 ， 拿 来 主义 即 可 ! 不 过 ， 大 
家 可 以 看 看 源 代码 ， 特 别 是 调试 时 ， 只 要 看 到 类 似 $Proxy0 这 样 的 结 
构 ， 你 就 应 该 知道 这 是 一 个 动态 代理 了 。 


友情 提醒 ， 在 学 习 AOP 框 染 时 ， 弄 清楚 几 个 名 词 就 成 : 切面 
(Aspect) “切入 点 (JoinPoint) 、 通 知 (Advice) 、 织 入 (Weave) 
瓯 足够 了 了， 理解 了 这 几 个 名 词 ， 应 用 时 你 束 可 以 游 才 有 余 了 ! 


13.1 个 性 化 电子 账单 


现在 电子 账单 越 来 越 流 行 了 ， 比 如 你 的 信用 卡 ， 每 到 月 初 的 时 候 
银行 束 会 发 一 份 电子 邮件 给 你 ， 说 你 这 个 月 消费 了 多 少 ， 什 么 时 候 消 
费 的 ， 积 分 是 多 少 等 ， 这 十 每 个 月 发 一 次 。 还 有 一 种 也 是 银行 发 的 邮 
件 你 肯定 非常 有 印象 : 广告 信 ， 现 在 各 大 银行 的 信用 卡 部 门 都 在 拉拢 
客户 ， 电 子 邮件 是 一 种 廉价 、 快 捷 的 通信 方式 ， 你 用 纸 质 的 广告 信 那 
个 费用 多 高 呀 ， 比 如 我 行 今天 推出 一 个 信用 卡 刷卡 抽奖 活动 ， 通 过 电 
子 账单 系统 可 以 一 个 晚上 发 送 给 600 万 客户 ， 为 什么 要 用 电子 账单 系统 
呢 ? 直接 找 个 发 垃圾 邮件 的 工具 不 就 解决 问题 了 吗 ? 是 个 好 主意 ， 但 
征 这 个 方案 在 金融 行业 是 行 不 通 的 ， 为 什么 ? 因为 银行 发 送 该 天 邮件 
征 有 要 求 的 : 


e 个 性 化 服务 


一 般 银行 都 要 求 个 性 化 服务 ， 发 过 去 的 邮件 上 总 有 一 些 个 人 信息 
吧 ; : 尼 如 WX 元 全" “WX 


e 名 太 成 功率 


邮件 的 递送 成 功率 有 一 定 的 要 求 ， 由 于 大 批量 地 发 送 邮 件 会 被 接 
收 方 邮件 服务 人 右 误 认 是 垃圾 邮件 ， 因 此 在 邮件 头 妥 增加 一 些 伪造 数 
据 ， 以 规避 和 被 反 垃圾 邮件 引擎 误 认 为 是 垃圾 邮件 。 


从 这 两 方面 考虑 广告 信 的 发 送 也 是 电子 账单 系统 (电子 账单 系统 
一 般 包括 : 账单 分 析 、 账 单 生成 器 、 广 告 信 管 理 、 发 送 队 列 管理 、 发 
送 机 、 退 信 处 理 、 报 表 管 理 等 ) 的 一 个 子 功能 ， 我 们 今天 就 来 考虑 一 
下 广告 信 这 个 模块 是 怎么 开发 的 。 那 既然 是 广告 信 ， 肯 定 需要 一 个 模 
板 ， 然 后 再 从 数据 库 中 把 客户 的 信息 一 个 一 个 地 取出 ， 放 到 模板 中 生 
成 一 份 完整 的 邮件 ， 然 后 扔 给 发 送 机 进行 发 送 处 理 ， 类 图 如 图 13-1 所 


修 ° 


在 类 图 中 AdvTemplate 是 广告 信 的 模板 ， 一 般 都 是 从 数据 库 取出 ， 
生成 一 个 BO 或 者 是 DTO， 我 们 这 里 使 用 一 个 静态 的 值 来 作 代 表 ; Mail 
类 是 一 封 邮 件 类 ， 发 送 机 发 送 的 就 是 这 个 类 。 我 们 先 来 看 
AdvTemplate， 如 代码 清单 13-1 所 示 。 


-String receiver 
-String subject 
-String appellation 
-String contxt 
-String tail 


tHMaill(AdvTemplate advTemplate) 
+getter/setter() 


AdvTemplate 


-Strng advSubject = 
-Strng advContext = 


+String getAdvSubject() 
+Strng getAdvContext() 


图 13-1 发 送 电 子 账 单 类 图 


代码 清单 13-1 广告 信 模 板 代码 


public class AdvTemplate { 


国庆 信用 卡 抽奖 活动 "， 


国庆 提 


// 广 告 信 名 称 
private String advSubject ="XX 银 行 
// 广 告 信 内 容 
private String advContext = " 
Hl 
// 取 得 广告 信 的 名 称 
public String getAdvSubject(){ 
return this.advSubject; 
} 
// 取 得 广告 信 的 内 容 
public String getAdvContext(){ 
return this.advContext,; 
} 
} 


邮件 类 Mail 如 代码 清单 13-2 所 示 。 


代码 清单 13-2 邮件 类 代码 


奖 活动 通知 : 只 要 刷卡 就 送 你 一 百 


public class Mail { 

// 收 件 人 

private String receiver; 

// 邮 件 名 称 

private String subject; 

// 称 请 

private String appellation; 

// 邮 件 内 容 

private String contxt; 

// 邮 件 的 尾部 ， 一 般 都 是 加 上 "XXX 版 权 所 有 "等 信息 

private String tail; 

// 构 造 本 数 

public Mail(AdvTemplate advTemplate)t{ 
this.contxt = advTemplate.getAdvContext(); 
this.subject = advTemplate.getAdvSubject(); 


} 

// 以 下 为 getter/setter 方 法 

public String getReceiver() { 
return receiver; 


public void setReceiver(String receiver) { 
this.receiver = receiver; 


public String getSubject() { 
return subject; 


public void setSubject(String subject) { 
this.subject = subject; 


} 
public String getAppellation() { 
return appellation; 


} 
public void setAppellation(String appellation) { 
this.appellation = appellation; 


} 
public String getContxt() { 
return contxt,; 


public void setContxt(String contxt) { 
this,.contxt = contxt; 


} 
public String getTail() { 
return tail,; 


public void setTail(String tail) { 
this.tail = tail; 
} 


Mail 类 束 是 一 个 业务 对 象 ， 虽 然 比 较 长 ， 还 是 比较 简单 的 。 我 们 
再 来 看 业务 场景 类 是 如 何 对 邮件 继续 处 理 的 ， 如 代码 清单 11-3 所 示 。 


代码 清单 13-3 场景 类 


public class Client { 
// 发 送 账单 的 数量 ， 这 个 值 是 从 数据 库 中 获得 
private static int MAX _ COUNT = 6; 
public static void main(String[] args) { 


// 模 拟 发 送 邮件 
int i=0; 
// 把 模板 定义 出 来 ， 这 个 是 从 数据 库 中 获得 


Mail mail = new Mail(new AdvTemplate( )); 

mail,setTail( "XX 银行 版 权 所 有 "); 

while(i<MAX_COUNT){ 
// 以 下 是 每 封 邮件 不 同 的 地 方 
mail.setAppellation(getRandsString(5)+" 移 


生 (女士 )")， 
mail.setReceiver(getRandString(5)+"@"+getRandString(8) +".com"); 
// 然 后 发 送 邮件 
sendMail(mail); 
i++，; 
} 
} 入 :汪汪 
// 发 送 邮件 


public static void sendMail(Mail mail)f{ 
System.out .println(" 标 题 "+mail.getSubject() + "Nt 
收 件 人 : 
"+mail.getReceiver()+"\t,. ,发送 成 功 !")， 


} 

// 获 得 指定 长 度 的 随机 字符 串 

public static String getRandString(int maxLength)t{ 
String source 

="abcdefghijklmnopqrskuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"，; 

StringBuffer sb = new StringBuffer(); 
Random rand = new Random( ) ; 
for(int i=0;i<maxLength;i++){ 


sb.append(source.charAt(rand.nextInt(source.1length()))); 


return sb.toString(); 
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} 
运行 结果 如 下 所 示 : 

标题 : XX 银行 国 庆 信 用 卡 收 件 人 : .发 送 成 
抽奖 活动 fijQUm@ZnkyPSsL.com 功 ! 

标题 : XX 银 行 国庆 信用 卡 收 件 人 : 二 发 达成 
抽奖 活动 ZIKnC@NOKdloNM.com Bh! 

标题 : XX 银行 国庆 信用 卡 收 件 人 : .发 送 成 
抽奖 活动 zNkMI@HpMMSZaz.com 功 ! 

标题 : XX 银 行 国庆 信用 卡 收 件 人 : .发 送 成 
抽奖 活动 oMTFA@uBwkRjxa.com 功 ! 

标题 : XX 银 行 国庆 信用 卡 收 件 人 : .发 送 成 
抽奖 活动 TquWT@TLLVNFja.com Dh 

标题 : XX 银 行 国庆 信用 卡 收 件 人 : .发 送 成 
抽奖 活动 rkQbp@mfATHDQH.com 功 ! 


由 于 古 随机 数 ， 每 次 运行 都 有 所 差异 ， 不 管 怎么 样 ， 我 们 这 个 电 
子 账单 发 送 程序 是 编写 出 来 了 ， 也 能 正常 发 送 。 我 们 再 来 仔细 地 想 
想 ， 这 个 程序 是 否 有 问题 ? Look here， 这 是 一 个 线程 在 运行 ， 也 就 是 
你 发 送 的 是 单线 程 的 ， 那 按照 一 封 邮 件 发 出 去 需要 0.02 秒 〈 够 小 了 ， 你 
还 要 到 数据 库 中 取 数 据 呢 ) ，600 万 封 邮 件 需 要 33 个 小 时 ， 也 就 是 一 个 
整 天 都 发 送 不 完 ， 今 天 的 没 发 送 完 ， 明 天 的 账单 又 产生 了 ， 日 积 月 
标 ， 激 起 甲 方 人 员 一 堆 抱 她 ， 那 怎么 办 ? 


好 办 ， 把 sendMail 修 改 为 多 线程 ， 但 是 只 把 sendMail 修 改 为 多 线程 
还 是 有 问题 的 呀 ， 产 生 第 一 封 邮件 对 象 ， 放 到 线程 1 中 运行 ， 还 没有 发 
送出 去 ; 线程 2 也 启动 了 ， 直 接 束 把 邮件 对 象 mail 的 收 件 人 地 址 和 称谓 


修改 掉 了 ， 线 程 不 安全 了 。 说 到 这 里 ， 你 会 说 这 有 N 多 种 解决 办 法 ， 其 
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中 一 种 是 使 用 一 种 新 型 模式 来 解决 这 个 问题 : 通过 对 象 的 复制 功能 3 
解决 这 个 问题 ， 类 图 稍 做 修改 ， 如 图 13-2 所 示 。 


<<mterface>> 
Cloneable 


AdvTemplate 


-Strng advSubject = "™ 
-String advContext = ”” 


-String receiver 
-Strng subject 
-Strmg appellation os 一 一 — 
e 十 IT 人 Pu DY 
-String contxt Strng getAdvSubject() 


-String tail +Strng getAdvContext() 


+Mail(AdvTemplate advTemplate) 
+Mail clone() 
tgetter/setter() 


让 < 
EE 4 


图 13-2 修改 后 的 发 送 电 子 账 单 类 图 


增加 了 一 个 Cloneable 接 口 (Java 自 带 的 一 个 接口 ， Mail 实 现 了 


这 个 接口 ， 在 Mail 类 中 获 写 clone0 方 法 ， 我 们 来 看 Mail 类 的 改变 ， 如 代 
码 清 单 13-4 所 示 。 


代码 清单 13-4 修改 后 的 邮件 类 


public class Mail implements Cloneablef{ 

// 收 件 人 

private String receiver; 

// 邮 件 名 称 

private String subject; 

// 称 请 

private String appellation; 

// 邮 件 内 容 

private String contxt; 

// 邮 件 的 尾部 ， 一 般 都 是 加 上 "XXX 版 权 所 有 "等 信息 

private String tail; 

// 构 造 本 数 

public Mail(AdvTemplate advTemplate)t{ 
this.contxt = advTemplate.getAdvContext(); 
this.subject = advTemplate.getAdvSubject(); 


Q@Override 
public Mail clone(){ 
Mail mail =null; 
try { 
mail = (Mail)super.clone(); 
} catch (CloneNotSupportedException e) { 
// TODO Auto-generated catch block 
e,printStackTrace( ); 


} 


return mail; 


} 

// 以 下 为 getter/setter 方 法 

public String getReceiver() { 
return receiver; 


public void setReceiver(String receiver) { 
this.receiver = receiver; 


} 
public String getSubject() { 
return subject; 


public void setSubject(String subject) { 
this.subject = subject; 


} 
public String getAppellation() { 
return appellation; 


} 
public void setAppellation(String appellation) { 
this.appellation = appellation; 


} 
public String getContxt() { 
return contxt,; 


} 
public void setContxt(String contxt) { 
this,.contxt = contxt; 


} 
public String getTail() { 
return tail,; 


} 

public void setTail(String tail) { 
this.tail = tail; 

} 


我 们 再 来 看 场景 Client 的 变化 ， 如 代码 清单 13-5 所 示 。 


代码 清单 13-5 修改 后 的 场景 ; 


public class Client { 
// 发 送 账单 的 数量 ， 这 个 值 是 从 数据 库 中 获得 
private static int MAX_ COUNT = 6; 
public static void main(String[] args) { 


// 模 拟 发 送 邮 件 
int i=0,; 
// 把 模板 定义 出 来 ， 这 个 是 从 数据 中 获得 


Mail mail = new Mail(new AdvTemplate( )); 
mail.setTail( "XX 银行 版 权 所 有 "); 
while(i<MAX COUNT){ 
// 以 下 是 每 封 邮件 不 同 的 地 方 
Mail cloneMail = mail.clone(); 
cloneMail.setAppellation(getRandString(5)+" 


先生 (女士 ) "); 
cloneMail.setReceiver(getRandString(5)+"@"+getRandString(8)+".co 
m"); 

// 然 后 发 送 邮 件 

sendMail(cloneMail ); 

i++; 

} 
} 

} 


运行 结果 不 变 ， 一样 完成 了 电子 广告 信 的 发 送 功 能 ， 而 且 sendMail 
即使 是 多 线程 也 没有 关系 。 注 意 ， 看 Client 类 中 的 粗 体 字 mail.clone() 这 


个 方法 ， 把 对 象 复制 一 份 ， 产 生 一 个 新 的 对 象 ， 和 原 有 对 象 一 样 ， 然 
后 再 修改 细 市 的 数据 ， 如 设置 称谓 、 设 置 收 件 人 地 址 等 。 这 种 不 通过 
new 关 键 字 来 产生 一 个 对 象 ， 而 是 通过 对 象 复制 来 实现 的 模式 就 叫做 原 
型 模式 。 


13.2 原型 模式 的 定义 
原型 模式 (Prototype Pattern) 的 简单 程度 仅 次 于 单 例 模式 和 迭代 
铝 模 式 。 正 是 由 于 简单， 使 用 的 场景 才 非 常 地 多 ， 其 定义 如 下 : 


Specify the kinds of objects to create using a prototypical instance,and 
create new objects by copying this prototype. (用 原型 实例 指定 创建 对 象 
的 种 类 ， 并 且 通 过 找 贝 这 些 原型 创建 新 的 对 象 。) 


原型 模式 的 通用 类 图 如 图 13-3 所 示 。 


Client +prototype 


Prototype 


+clone() 


ConcretePrototype 
| 
3 
图 13-3 原型 模式 的 通用 类 图 


简单 ， 太 简单 了 ! 原型 模式 的 核心 是 一 个 clone 方 法 ， 通 过 该 方法 
进行 对 象 的 拷贝 ，Java 提 供 了 一 个 Cloneable 接 口 来 标示 这 个 对 象 是 可 搂 
贝 的 ， 为 什么 说 是 “标示 ” 呢 ? 翻 开 JDK 的 帮助 看 看 Cloneable 是 一 个 方法 
都 没有 的 ， 这 个 接口 只 是 一 个 标记 作用 ， 在 JVM 中 具有 这 个 标记 的 对 
象 才 有 可 能 被 拷贝 。 那 怎么 才能 从 “有 可 能 被 拷贝 "转换 为 “可 以 被 找 
贝 " 呢 ? 方法 是 覆盖 clone(0) 方 法 ， 是 的 ， 你 没有 看 错 是 重 写 clone() 方 
法 ， 看 看 我 们 上 面 Mail 类 中 的 clone 方 法 ， 如 代码 清单 13-6 所 示 。 


代码 清单 13-6 邮件 类 中 的 clone 方 法 


@Override 
public Mail clone(){} 


注意 ， 在 cdlone() 方 法 上 增加 了 一 个 注解 @Override， 没 有 继承 一 个 
类 为 什么 可 以 履 写 呢 ? 想 想 看 ， 在 Java 中 所 有 类 的 老 祖 宗 是 谁 ? 对 噬 ， 
Object 类 ， 每 个 类 默认 都 是 继承 了 这 个 类 ， 所 以 用 禾 写 是 非常 正确 的 
一 一 复写 了 Object 类 中 的 Clone 方法 


在 Java 中 原型 模式 是 如 此 简单， 我 们 来 看 通用 源 代 码 ， 如 代码 清单 
13-7 所 示 。 


代码 清单 13-7 原型 模式 通用 源码 


public class PrototypeClass implements Cloneablef 
// 履 写 父 类 0bject 方 法 
@Override 
public PrototypeClass clone(){ 
PrototypeClass prototypeClass = null; 
try { 


prototypeClass = 
(PrototypeClass)super.clone(); 
} catch (CloneNotSupportedException e) { 
// 寞 常 处 理 


return prototypeClass; 


实现 一 个 接口 ， 然 后 重 写 clone 方 法 ， 就 完成 了 原型 模式 ! 


13.3 原型 模式 的 应 用 
13.3.1 原型 模式 的 优点 


e 性 能 优 民 


原型 模式 是 在 内 存 二 进 制 流 的 拷贝 ， 要 比 直接 new 一 个 对 象 性 能 
好 很 多 ， 等 别 是 要 在 一 个 循环 体内 产生 大 量 的 对 象 时 ， 原 型 模式 可 以 
更 好 地 体现 其 优点 。 


e 逃避 构造 男 数 的 约束 


这 既是 它 的 优点 也 是 缺 操 ， 直 接 在 内 存 中 拷贝 ， 构 造 画 数 是 不 会 
执行 的 “参见 13.4 节 ) 。 优 点 就 是 减少 了 约束 ， 缺 点 也 是 减少 了 约 
束 ， 需 要 大 家 在 实际 应 用 时 考虑 。 


13.3.2 原型 模式 的 使 用 场景 


e 资源 优化 场景 


类 初始 化 需要 消化 非常 多 的 资源 ， 这 个 资源 包括 数据 、 硬 件 资 源 
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e 性 能 和 安全 要 求 的 场景 


通过 new 产 生 一 个 对 象 需要 非常 尝 琐 的 数据 准备 或 访问 权限 ， 则 
可 以 使 用 原型 模式 。 


e 一 个 对 象 多 个 修改 者 的 场景 


一 个 对 象 需要 提供 给 其 他 对 象 访问 ， 而 且 各 个 调用 者 可 能 都 需要 
修改 其 值 时 ， 可 以 考虑 使 用 原型 模式 拷贝 多 个 对 象 供 调用 者 使 用 。 


在 实际 项 目 中 ， 原 型 模式 很 少 单独 出 现 ， 一 般 是 和 工厂 方法 模式 
一 起 出 现 ， 通 过 clone 的 方法 创建 一 个 对 象 ， 然 后 由 工厂 方法 提供 给 调 
用 者 。 原 型 模式 已 经 与 Java 融 为 一 体 ， 大 家 可 以 随手 拿 来 使 用 。 


13.4 原型 模式 的 注意 事项 


原型 模式 虽然 很 简单 ， 但 是 在 Java 中 使 用 原型 模式 也 就 是 clone 方 
征 有 一 些 广 意 事项 的 ， 我 们 通过 几 个 例子 逐个 解说 。 


13.4.1 构造 辑 数 不 会 侦 执 行 


一 个 实现 了 Cloneable 并 重 写 了 clone 方 法 的 类 A， 有 一 个 无 参 构造 
或 有 参 构 造 B， 通 过 new 关 键 字 产 生 了 一 个 对 象 $5， 再 然后 通过 S.clone() 
方式 产生 了 一 个 新 的 对 象 T， 那 么 在 对 象 拷贝 时 构造 函数 B 是 不 会 被 执 
行 的 。 我 们 来 写 一 小 段 程序 来 说 明 这 个 问题 ， 如 代码 清单 13-8 所 示 。 


代码 清单 13-8 简单 的 可 拷贝 对 象 


public class Thing implements Cloneablef{ 
public Thing( ){ 
System,out.println(" 构 造 画 数 被 执行 了 ,.."); 


QOverride 
public Thing clone(){ 
Thing thing=null; 


try { 
thing = (Thing)super.clone(); 

} catch (CloneNotSupportedException e) { 
e.printStackTrace( ) ; 


return thing; 


然后 我 们 再 来 写 一 个 Client 类 ， 进 行 对 象 的 搁 贝 ， 如 代码 清单 13-9 
所 有 


代码 请 单 13-9 简单 的 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 产 生 一 个 对 象 
Thing thing = new Thing(); 
// 找 贝 一 个 对 象 
Thing cloneThing = thing.clone(); 
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运行 结 采 如 下 所 示 : 

构造 函数 被 执行 了 .… 

对 象 拷贝 时 构造 函数 确实 没有 被 执行 ， 这 点 从 原理 来 讲 也 是 可 以 
讲 得 通 的 ，Object 类 的 clone 方 法 的 原理 是 从 内 存 中 (具体 地 说 就 是 堆 
内 存 ) 以 二 进 制 流 的 方式 进行 拷贝 ， 重 新 分 配 一 个 内 存 块 ， 那 构造 画 
数 没 有 被 执行 也 是 非 肖 正常 的 了 。 


13.4.2 浅 拷贝 和 深 找 贝 


在 解释 什么 古 浅 找 贝 和 什么 是 深 堵 贝 之 前 ， 我 们 先 来 看 个 例子 ， 
如 代码 清单 13-10 所 示 。 


代码 清单 13-10 浅 找 贝 


public class Thing implements CJLoneab]et{ 
// 定 义 一 个 私有 变量 
private ArrayList<String> arrayList = new 
ArrayList<String>(); 
@Override 
public Thing clone(){ 
Thing thing=null; 
try { 


thing = (Thing)super.clone(); 
} catch (CloneNotSupportedException e) { 
e.printStackTrace( ); 


return thing; 


下 

// 设 置 HashMap 的 值 

public void setValue(String value)t{ 
this.arrayList.add(value); 

} 


// 取 得 arrayList 的 值 

public ArrayList<String> getValue(){ 
return this.arrayList; 

} 


在 Thing 类 中 增加 一 个 私有 变量 arrayLis， 类 型 为 ArrayList， 然 后 
通过 setValue 和 getValue 分 别 进行 设置 和 取 值 ， 我 们 来 看 场景 类 是 如 何 
拷贝 的 ， 如 代码 祖 单 13-11 所 示 。 


代码 清单 13-11 浅 拷贝 测试 


public class Client { 
public static void main(String[] args) { 


// 产 生 一 个 对 象 

Thing thing = new Thing(); 
// 设 置 一 个 值 
thing.setValue(" 张 三 ")，; 

// 拷 贝 一 个 对 象 


Thing cloneThing = thing.clone(); 
cloneThing.setValue(" 李 四 ")，; 
System.out,println(thing.getValue() )，; 


猜想 一 下 运行 结果 应 该 是 什么 ? 是 仅 一 个 “ 张 三 ” 吗 ? 运行 结果 如 
下 所 示 ， 


[ 张 三 ， 李 四 ] 


怎么 会 这 样 呢 ? 怎么 会 有 李 四 呢 ? 是 因为 Java 做 了 一 个 偷懒 的 搁 
贝 动作 ，Object 类 提供 的 方法 clone 只 是 拷贝 本 对 象 ， 其 对 象 内 部 的 数 
组 、 引 用 对 和 象 等 都 不 拷贝 ， 还 是 指向 原生 对 象 的 内 部 元 素 地 址 ， 这 种 
拷贝 吏 叫做 浅 搁 贝 。 确 实 是 非常 线 ， 两 个 对 象 共享 了 一 个 私有 变量 ， 
你 改 我 改 大 家 都 能 改 ， 是 一 种 非常 不 安全 的 方式 ， 在 实际 项 目 中 使 用 
还 是 比较 少 的 〈 当 然 ， 这 也 是 一 种 “危机 ?环境 的 一 种 救命 方式 ) 。 你 
可 能 会 比较 奇怪 ， 为 什么 在 Mail 那 个 类 中 束 可 以 使 用 String 类 型 ， 而 不 
会 产生 由 浅 拷贝 带 来 的 问题 呢 ? 内 部 的 数组 和 引用 对 象 才 不 拷贝 ， 其 
他 的 原始 类 型 比如 int、long、char 等 都 会 被 找 贝 ， 但 是 对 于 String 类 
型 ，Java 就 布 望 你 把 它 认 为 是 基本 类 型 ， 它 是 没有 clone 方 法 的 ， 处 理 
机 制 也 比较 特殊 ， 通 过 字符 串 池 (stringpool) 在 需要 的 时 候 才 在 内 存 
中 创建 新 的 字符 串 ， 读 者 在 使 用 的 时 候 束 把 String 当 做 基本 类 使 用 即 
可 。 


注意 “使 用 原型 模式 时 ， 引 用 的 成 员 变 量 必 须 满足 两 个 条 件 才 不 
会 被 拷贝 : 一 是 类 的 成 员 变 量 ， 而 不 是 方法 内 变量 ; 二 是 必须 是 一 个 


可 变 的 引用 对 象 ， 而 不 是 一 个 原始 类 型 或 不 可 变 对 象 。 


浅 拷贝 是 有 风险 的 ， 那 怎么 才能 深入 地 拷贝 呢 ? 我 们 修改 一 下 程 
序 束 可 以 深 堵 贝 ， 如 代码 清单 13-12 所 示 。 


代码 清单 13-12 深 找 贝 


public class Thing implements Cloneablef{ 
// 定 义 一 个 私有 变量 
private ArrayList<String> arrayList = new 
ArrayList<String>(); 
@Override 
public Thing clone(){ 
Thing thing=null; 
try { 


thing = (Thing)super.clone(); 
thing.arrayList = 
(ArrayList<String>)this.arrayList.clone(); 
} catch (CloneNotSupportedException e) { 
e.printStackTrace( ); 


return thing; 


ww 


运行 结 末 如 下 所 示 : 
[ 张 三 ] 
该 方法 整 实现 了 完全 的 拷贝 ， 两 个 对 象 之 间 没 有 任何 的 内 万 了 ， 
你 修改 你 的 ， 我 修改 我 的 ， 不 相互 影响 ， 这 种 拷贝 就 叫做 深 堵 贝 。 深 
找 贝 还 有 一 种 实现 方式 吕 是 通过 目 己 写 二 进 制 流 来 操作 对 象 ， 然 后 实 
现 对 象 的 深 堵 贝 ， 这 个 大 家 有 时 间 目 己 实现 一 下 。 


注意 深 找 贝 和 浅 拷贝 建议 不 要 混合 使 用 ， 特 别 是 在 涉及 类 的 继 
承 时 ， 父 类 有 多 个 引用 的 情况 束 非 常 复杂 ， 建 议 的 方案 是 深 找 贝 和 浅 
拷贝 分 开 实现 。 


13.4.3 clone 与 final 两 个 揭 家 


对 和 象 的 clone 与 对 象 内 的 final 关 键 字 是 有 神 突 的 ， 我 们 举例 来 说 明 
这 个 问题 ， 如 代码 清单 13-13 所 示 。 


代码 清单 13-13 增加 final 关 键 子 的 拷贝 


public class Thing implements Cloneablef{ 
// 定 义 一 个 私有 变量 
private final ArrayList<String> arrayList = new 
ArrayList<String>(); 
@Override 
public Thing clone(){ 
Thing thing=null; 
try 1{ 


thing = (Thing)super.clone(); 
this.arrayList = 
(ArrayList<String>)this.arrayList.clone(); 
} catch (CloneNotSupportedException e) { 
e.printStackTrace( ); 


return thing; 


仅仅 增加 了 一 个 final 天 键 子 ， 然 后 编译 如 谍报 斜体 部 分 错误 ， 正 
常 呀 ，final 类 型 你 还 想 重 赋值 呀 ! 你 要 实现 深 拷贝 的 梦想 在 final 天 键 


字 的 威胁 下 破 炙 了 ， 路 总 是 有 的 ， 我 们 来 想 想 怎么 修改 这 个 方法 ， 删 
除 掉 final 关 键 子 ， 这 十 最 便捷 、 安 全 、 快 速 的 方式 。 你 要 使 用 clone 方 
法 ， 在 类 的 成 员 变 量 上 束 不 要 增加 final 关 键 子 。 


注意 ”要 使 用 clone 方 法 ， 类 的 成 员 变 量 上 不 要 增加 final 关 键 字 。 


13.5 最 住 实 践 


原型 模式 先 产 生出 一 个 包含 大 量 共 有 信息 的 类 ， 然 后 可 以 拷贝 出 
副本 ， 修 正 细 市 信息 ， 建 立 了 一 个 完整 的 个 性 对 象 。 不 知道 大 家 有 没 
有 看 过 施 瓦 茸 格 演 的 《第 六 日 》 这 部 电影 ， 电 影 的 主线 也 束 是 一 个 人 
被 复制 ， 然 后 正本 和 副本 对 扫 。 我 们 今天 讲 的 原型 模式 也 束 是 由 一 个 
正本 可 以 创建 多 个 副本 的 概念 。 可 以 这 样 理 解 : 一 个 对 象 的 产生 可 以 
不 由 零 起 步 ， 直 接 从 一 个 已 经 具备 一 定 委 形 的 对 象 苑 隆 ， 然 后 再 修改 
为 生产 需要 的 对 象 。 也 吏 是 说 ， 产 生 一 个 人 ， 可 以 不 从 1 罗 长 到 2 罗 ， 
再 到 3 多 .…… 也 可 以 直接 找 一 个 人 ， 从 其 身上 获得 DNA， 然 后 克隆 一 
个 ， 直 接 修 改 一 下 就 是 30 岁 了 ! 我 们 讲 的 原型 模式 也 就 是 这 样 的 功 
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第 14 章 ”中 介 痢 模式 


14.1 进 销 存 管理 是 这 个 样子 的 吗 


大 家 部 来 日 五 湖 四 海 ， 部 要 生存 ， 于 是 都 找 了 个 靠山 一 一 公司 ， 
就 是 给 你 发 薪水 的 地 方 。 公 司 要 想 尽 办 法 赢利 赚钱 ， 启 利 方法 则 不 尽 
相同 ， 但 是 各 个 公司 都 有 相同 的 三 个 环 订 : 采购 、 销 售 和 库存 。 这 个 
皇 么 说 呢 ? 比如 一 个 软件 公司 ， 要 开发 软件 ， 吏 需要 购买 开发 环境 ， 
如 Windows 操 作 系统 、 数 据 库 产品 等 ， 这 驶 是 采购 ; 开发 完 产 品 还 要 把 
产品 推销 出 去 ， 有 产品 就 必然 有 库存 ， 软 件 产 品 也 有 库存 ， 虽 然 不 需 
要 占用 库房 空间 ， 但 也 要 占用 光 强 或 硬盘 ， 这 也 是 库存 。 再 比如 做 咨 
询 服 务 的 公司 ， 它 要 采购 什么 ? 采购 知识 ， 采 购 经 验 ， 这 是 这 类 企业 
的 生存 之 本 ， 销 售 的 也 是 知识 和 经 验 ， 库 存 同 样 是 知识 和 经 验 。 有 既然 
进 销 存 是 如 此 重要 ， 我 们 今天 就 来 讲 讲 它 的 原理 和 设计 ， 我 相信 很 多 
人 痢 已 经 开发 过 这 种 类 型 的 软件 ， 基 本 上 都 形成 了 固定 套路 ， 不 管 古 
单机 版 还 是 网 络 版 ,一般 的 做 法 部 是 通过 数据 库 来 完成 相关 产品 的 管 
理 ， 相 对 来 说 这 还 是 比较 简单 的 项 目 ， 三 个 模块 的 示意 图 如 图 14-1 所 
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图 14-1 进 销 存 示意 图 


我 们 从 这 个 示意 图 上 可 以 看 出 ， 三 个 模块 是 相互 依赖 的 。 我 们 惑 
以 一 个 终端 销售 商 《以 服务 最 终 客户 为 目标 的 企业 ， 比 如 某 某 超市 、 
某 某 商 店 等 ) 为 例 ， 采 购 部 门 要 采购 IBM 的 电脑 ， 它 根据 以 下 两 个 要 
素来 决定 采购 数量 。 


。 销售 情况 
销售 部 门 要 反馈 销售 情况 ， 畅 销 就 多 采购 ， 请 销 就 不 采购 。 


e 库存 情况 


即使 是 畅销 产品 ， 库 存 都 有 1000 台 了 ， 每 天 才 卖 出 去 10 台 ， 也 就 
不 需要 再 采购 了 ! 


销售 模块 是 企业 的 说 利 核 心 ， 对 其 他 两 个 模块 也 有 影响 : 


e 库存 情况 
库房 有 货 ， 才 能 销售 ， 空 手 爸 白 狼 是 不 行 的 。 
e 督促 采购 


在 特殊 情况 下 ， 比 如 一 个 企业 客户 要 一 次 性 购买 100 台 电脑 ， 库 存 
只 有 80 台 ， 这 时 需要 催促 采购 部 门 赶快 采购 ! 


同样 地 ， 库 存 管理 也 对 其 他 两 个 模块 有 影响 。 库 房 症 有 容积 限制 
的 ， 不 可 能 无 限 大 ， 所 以 就 有 了 清仓 处 理 ， 那 束 要 求 采 购 部 门 停 止 采 
购 ， 同 时 销售 部 门 进行 打折 销售 。 


从 以 上 分 析 来 看 ， 这 三 个 模块 都 有 目 己 的 行为 ， 并 且 与 其 他 模块 
之 间 的 行为 产生 关联 ， 类 似 于 我 们 办 公 室 的 同事 ， 大 家 各 干 各 的 活 ， 
但 古 彼此 之 间 还 是 有 交 义 的 ， 于 古 彼 此 之 间 束 产生 紧 糊 合 ， 也 束 古 一 
个 团队 。 我 们 先 来 实现 这 个 进 销 存 ， 类 图 如 图 14-2 所 示 。 


Purchase 刀 


+void sellBMComputer(int number) 
+mt getSaleStatus() 
+void offSale() 


+void increase(int number) 
+vold decrease(nt number) 
+int getStockNumber() 
tHvoid clearStock() 


图 14-2 简单 的 进 销 存 类 疼 


下 采购 管理 ，buyIBMCompnuter 指 定 了 采购 IBM 电 脑 ， 


refuseBuyIBM 是 指 不 再 采购 IBM 了 ， 源 代码 如 代码 清单 14-1 所 示 。 


代码 清单 14-1 采购 管理 


public class Purchase { 
// 采 购 IBM 电 脑 
public void buyIBMcomputer(int number){ 


"人 台 "); 


// 访 问 库 存 
Stock stock = new Stock(); 


// 访 问 销售 
Sale Sale = new Salel() 
// 电 脑 的 销售 情况 


int SaleStatus = Sale,.getSaleStatus( ) ， 
if(saleStatus>80){ // 销 售 情况 良好 
System.out.println(" 采 购 IBM 电 脑 :"+number + 


stock.increase(number ) ， 

}else{ // 销 售 情况 不 好 
int buyNumber = number/2; // 折 半 采 购 
System.out.printlLn(" 采 购 IBM 电 脑 : "+buyNumber+ 
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刀 
人 
号 


"人 台 "); 


} 


} 
// 不 再 采购 IBM 电 脑 
public void refuseBuyIBM(){ 


System.out.println(" 不 再 采购 IBM 电 脑 ")，; 
} 


Purchase 定 义 了 采购 电脑 的 标准 : 如 果 销 售 情况 比较 好 ， 大 于 80 
分 ， 你 让 我 采购 多 少 我 瑟 采 购 多 少 ， 销 售 情况 不 好 ， 你 让 我 采购 100 
， 我 吏 采 购 50 台 ， 对 折 采 购 。 电 脑 采 购 完 毕 ， 需 要 放 到 库房 中 ， 


此 要 调用 库存 的 方法 ， 增 加 库存 电脑 数量 。 我 们 继续 来 看 库房 Stock 
类 ， 如 代码 清单 14-2 所 示 。 


代码 清单 14-2 库存 管理 


public class Stock { 


// 刚 开始 有 100 台 电脑 

private static int COMPUTER_NUMBER =100; 

// 库 存 增加 

public void increase(int number)t{ 
COMPUTER_NUMBER = COMPUTER_ NUMBER + number; 
System.out.println(" 库 存 数量 为 "+COMPUTER_NUMBER ) ; 


} 
// 库 存 降低 
public void decrease(int number)t{ 
COMPUTER_NUMBER = COMPUTER_ NUMBER - number; 
System.out.println(" 库 存 数量 为 : "+COMPUTER_NUMBER ) ; 


} 

// 获 得 库存 数量 

public int getStockNumber(){ 
return COMPUTER_NUMBER ， 


} 
// 存 货 压力 大 了 ， 束 要 通知 采购 人 员 不 要 采购 ， 销 售 人 员 要 尽快 销售 
public void clearStock(){ 
Purchase purchase = new Purchase( ); 
Sale sale = new Sale(); 
System,.,out.println(" 清 理 存货 数量 


"+COMPUTER_NUMBER ) ; 


// 要 求 折价 销售 
sale.offSale( ); 

// 要 求 采购 人 员 不 要 采购 
purchase.refuseBuyIBM( ) ; 


库房 中 的 货物 数量 肯定 有 增 减 ， 同 时 库房 还 有 一 个 容量 显示 ， 达 
到 一 定 的 容量 后 就 要 求 对 一 些 商品 进行 折价 处 理 ， 以 腾 出 更 多 的 空间 
容纳 新 产品 。 于 是 就 有 了 clearStock 方 法 ， 既 然 是 清仓 处 理 肯 定 就 要 折 
价 销售 了 。 于 是 在 Sale 类 中 就 有 了 offSale 方 法 ， 我 们 来 看 Sale 源 代码 ， 
如 代码 清单 14-3 所 示 。 


代码 清单 14-3 销售 管理 


public class Sale { 

// 销 售 IBM 电 脑 

public void sellIBMComputer(int number){ 
// 访 问 库存 
Stock stock = new Stock(); 
// 访 问 采购 
Purchase purchase = new Purchase( ); 
if(stock.getStockNumber()<number){ /7 库存 数 量 不 够 销售 

purchase.buyIBMcomputer (number ) 


System.out .println(" 销 售 IBM 电 脑 "+number+" 人 台 ")， 
stock.decrease(number ) ， 


} 
// 有 反馈 销 售 情况 ，0~~100 之 间 变 化 ，0 代 表 根 本 就 没 人 卖 ，100 代 表 非 常 畅 销 ， 
出 一 个 卖 一 个 
public int getSaleStatus()t{ 
Random rand = new 
Random(System.currentTimeMil]lis( )); 
int saleStatus = rand.nextInt(100); 
System.out.println("IBM 电 脑 的 销售 情况 
为 : "+SaleStatus ) ; 
return SaleStatus ， 


} 
// 折 价 处 理 
public void offSale(){ 


// 库 房 有 多 少 卖 多 少 

Stock Stock = new Stock(); 

System.out .println(" 折 价 销售 ITBM 电 
脑 "+stock.getStockNumber()+" 人 台 ")， 


} 
} 


Sale 类 中 的 getSaleStatus 是 狭 得 销售 情况 ， 这 个 当然 要 出 现在 Sale 类 
中 了 。 记 住 要 把 恰当 的 类 放 到 恰当 的 类 中 ， 销 售 情况 只 有 销售 人 员 才 
能 反馈 出 来 ， 通 过 百分制 的 机 制衡 量 销售 情况 。 我 们 再 来 看 场景 类 是 
后 么 运行 的 ， 场 景 类 如 代码 清单 14-4 所 示 。 


代码 清单 14-4 场景 


public class Client { 
public static void main(String[] args) { 

// 采 购 人 员 采 购 电脑 
System.out.println("------ 采购 人 员 采 购 电脑 -------- 
Purchase purchase = new Purchase( ); 
purchase.buyIBMcomputer(100); 
// 销 售 人 员 销 售 电脑 
System.out.println("\n------ 销售 人 员 销 售 电 脑 - - ------ 


"); 
Sale Sale = new Sale(); 
sale.sellIBMComputer(1); 
// 库 房管 理 人 员 管 理 库 存 
System.out.println("Nxn------ 库房 管理 人 员 清 库 处 理 ------ 


Stock stock = new Stock(); 
stock.clearStock(); 


我 们 在 场景 类 中 模拟 了 三 种 人 员 的 活动 : 采购 人 员 采 购 电脑 ， 销 
售 人 员 销 售 电脑 ， 库 管 员 管理 库存 。 运 行 结 果 如 下 所 示 : 


a 采购 人 员 采 购 电 脑 -------- 


IBM 电 脑 的 销售 情况 为 : 95 


采购 IBM 电 脑 :100 台 


库存 数量 为 : 200 


销售 IBM 电 脑 1 台 


清理 存货 数量 为 : 199 


折价 销售 IBM 电 脑 199 台 


不 再 采购 IBM 电 腑 


运行 结果 也 是 我 们 期 望 的 ， 三 个 不 同类 型 的 参与 者 完成 了 各 自 的 
活动 。 你 有 没有 发 现 这 三 个 类 十 彼此 关联 的 ? 每 个 类 都 与 其 他 两 个 类 
产生 了 关联 关系 。 迪 米 特 法 则 认为 “每 个 类 只 和 朋友 类 交流 ”， 这 个 朋 
友 类 并 非 越 多 越 好 ， 朋 友 类 越 多 ， 硝 合 性 越 大 ， 要 想 修改 一 个 束 得 修 
改 一 片 ， 这 不 是 面 癌 对 象 设计 所 期 望 的 ， 况 且 这 还 是 仅 三 个 模块 的 情 
况 ， 属 于 比较 简单 的 一 个 小 项 目 。 我 们 把 进 销 存 扩 展 一 下 ， 如 图 14-3 所 
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图 14-3 扩展 后 的 进 销 存 示意 图 


这 是 一 个 蜂 蛛 网 的 结构 ， 别 说 是 编写 程序 了 ， 丈 是 给 人 看 估计 也 
能 让 一 大 批 人 异 倒 ! 每 个 对 象 都 需要 和 其 他 几 个 对 象 交流 ， 对 象 越 
多 ， 每 个 对 象 要 交流 的 成 本 也 就 越 大 了 ， 只 是 维护 这 些 对 象 的 交流 惑 
能 让 一 大 批 程序 员 望 而 却步 ! 从 这 方面 来 说 ， 我 们 已 经 发 现 设计 的 缺 
陷 了 ， 作 为 一 个 架构 师 ， 发 现 缺陷 就 要 想 办 法 修改 。 


大 家 都 学 过 网 络 的 基本 知识 ， 网 络 拓扑 有 三 种 类 型 ， 总 线 型 、 环 
型 、 星 型 。 星 型 网 络 拓扑 如 图 14-4 所 示 。 


在 星 型 网 络 拓 扑 中 ， 每 个 计算 机 通过 交换 机 和 其 他 计算 机 进行 数 
据 交 换 ， 各 个 计算 机 之 间 并 没有 直接 出 现 交 互 的 情况 。 这 种 结构 简 
单 ， 而 且 稳 定 ， 只 要 中 间 那 个 交换 机 不 瘫痪 ， 整 个 网 络 整 不 会 发 生 大 
的 故障 。 公 司 和 网 吧 一 般 都 采用 星 型 网 络 。 我 们 是 不 是 可 以 把 这 种 星 
型 结构 引入 到 我 们 的 设计 中 呢 ? 我 们 先 画 一 个 示意 图 ， 如 图 14-5 所 示 。 


图 14-4 星 型 网 络 拓扑 
中 介 者 


图 14-5 修改 后 的 进 销 存 示意 图 


加 入 了 一 个 中 介 者 作为 三 个 模块 的 交流 核心 ， 每 个 模块 之 间 不 再 
相互 交流 ， 要 交流 束 通 过 中 介 者 进行 。 每 个 模块 只 负责 目 己 的 业务 逻 


辑 ， 不 属于 目 己 的 则 丢 给 中 介 者 来 处 理 ， 人 简化 了 各 模块 之 间 的 糊 合 关 
系 ， 类 图 如 图 14-6 所 示 。 


AbstractMediator 


#Purchase purchase 
#Sale sale 
+Stock stock 


+AbstractMediator() 
+void execute(String str, Object...objects) 


Purchase Mediator 
Eee 于 
+void buyIBMcompnuter(int number) +void execute(String str, Object...objects) +void sellBMComputer(int number) 
+void refuse BuyIBM() +int getSaleStatus() 
i +void offSale() 


+vold increase(nt number) 
+vold decrease(int number) 
+int getStockNumber() 
+void clearStock() 


AbstractColleague 
[| #AbstractMediator mediator 


+AbstractColleague(AbstractMediator mediator) 


图 14-6 修改 后 的 进 销 存 类 图 


建立 了 两 个 抽象 类 AbstractMediator 和 AbstractColeague， 每 个 对 象 
只 是 与 中 介 者 Mediator 之 间 产 生 依赖 ， 与 其 他 对 象 之 间 没 有 直接 关系 ， 
AbstractMediator 的 作用 是 实现 中 介 者 的 抽象 定义 ， 定 义 了 一 个 抽象 方 
法 execute， 如 代码 清单 14-5 所 示 。 


代码 清单 14-5 抽象 中 介 者 


public abstract class AbstractMediator { 
protected Purchase purchase 


protected Sale sale; 

protected Stock stock; 

// 构 造 函 数 

public AbstractMediator(){ 
purchase = new Purchase(this ) ; 
sale = new Sale(this) ; 
stock = new Stock(this ) 


} 
// 中 介 者 最 重要 的 方法 叫做 事件 方法 ， 处 理 多 个 对 象 之 间 的 关系 


GUbl Ie abstract void execute(String str,Object...objects); 


再 来 看 具体 的 中 介 者 ， 我 们 可 以 根据 业务 的 要 求 产 生 多 个 中 介 
者 ， 并 划分 各 中 介 着 的 职责 。 上 有 具体 中 介 着 如 代码 清单 14-6 所 示 。 


代码 清单 14-6 具体 中 介 者 


public class Mediator extends AbstractMediator { 

// 中 介 者 最 重要 的 方法 

public void execute(String str,Object...objects)t{ 

if(str.equals("purchase.buy")){ // 采 购 电 脑 

this.buyComputer((Integer)objects[0]); 

}else if(str.equals("sale.sell")){ // 销 售 电 脑 

this.sellComputer((Integer)objects[0]); 

}else if(str.equals("sale.offsel1l")){ // 折 价 销 
this.offSell(); 

}else if(str.equals("stock.clear")){ // 清 仓 处 理 

this.clearStock(); 


丙 


// 采 购 电脑 


private void buyComputer(int number ){ 
int SaleStatus = super.sale.getSalesStatus(); 
if(saleStatus>80){ // 销 售 情况 良好 
System.out.printlin(" 采 购 IBM 电 脑 :"+number + 


"人 台 "); 
super.stock.increase(number); 
}else{ // 销 售 情况 不 好 
int buyNumber = number/2; // 折 半 采 购 
System.out.print1Ln('" 巴 采购 IBM 电 脑 : "+buyNumber+ 
" 台 ") 


// 销 售 电脑 
private void sellComputer(int number){ 
if(super.stock.getStockNumber()<number){  // 库 存 数量 
不 够 销售 


[ 


super .purchase.buyIBMcomputer (number ) ; 


了 


super.stock.decrease(number ) ; 


} 
// 折 价 销 售 电 脑 
private void offSell(){ 
System.out.println(" 折 价 销售 ITBM 电 
脑 "+stock.getStockNumber()+" 人 台 "); 


} 

// 清 仓 处 理 

private void clearstock()t 
// 要 求 清仓 销售 
super .sale.offSale( ); 
// 要 求 采 购 人 员 不 要 采购 
super .purchase.refuseBuyIBM( ) ; 


中 介 者 Mediator 定 义 了 多 个 private 方 法 ， 其 目的 是 处 理 各 个 对 象 之 
间 的 依赖 关系 ， 束 是 说 把 原 有 一 个 对 象 要 依赖 多 个 对 象 的 情况 移 到 中 
os 法 中 实现 。 在 实际 项 目 中 ， 一 般 的 做 法 是 中 介 者 按照 职 
责 进 行 划分 ， 每 个 中 介 者 处 理 一 个 或 多 个 类 似 的 关联 请 求 。 


由 于 要 使 用 中 介 者 ， 我 们 增加 了 一 个 抽象 同事 类 ， 三 个 具体 的 实 
现 类 分 别 继 承 该 抽象 类 ， 如 代码 清单 14-7 所 示 。 


代码 清单 14-7 抽象 同事 类 


public abstract class AbstractColleague { 
protected AbstractMediator mediator; 
public AbstractColleague(AbstractMediator _mediator)t{ 
this.mediator = _mediator; 
} 


采购 Purchase 类 如 代码 清单 14-8 所 示 。 


代码 清单 14-8 修改 后 的 采购 管理 


public class Purchase extends AbstractCcolleaguet 
public Purchase(AbstractMediator _mediator){ 
Super(_mediator ) ; 


} 
// 采 购 IBM 电 脑 
public void buyIBMcomputer(int number){ 

super .mediator.execute("purchase.buy", number ) ; 


} 

// 不 再 采购 IBM 电 脑 

public void refuseBuyIBM( ){ 
System.out.printlLn(" 不 再 采购 IBM 电 脑 " ) ; 

} 


上 述 Purchase 类 简化 了 很 多 ， 也 清晰 了 很 多 ， 处 理 自 己 的 职责 ， 与 
外 界 有 关系 的 事件 处 理 则 交 给 了 中 介 者 来 完成 。 再 来 看 Stock 类 ， 如 代 
码 清单 14-9 所 示 。 


代码 清单 14-9 修改 后 的 库存 管理 


public class Stock extends AbstractColleague { 
public Stock(AbstractMediator _mediator)t{ 
super(_mediator ) ， 


} 
// 刚 开始 有 100 人 台电 脑 
private static int COMPUTER_NUMBER =100 ， 
// 库 存 增加 
public void increase(int number)t{ 
COMPUTER_ NUMBER = COMPUTER NUMBER + number; 
System.out.println(" 库 存 数量 为 : "+COMPUTER_NUMBER ) ; 


} 
// 库 存 降低 
public void decrease(int number){ 
COMPUTER_NUMBER = COMPUTER_ NUMBER - number; 
System.out.print1Ln(" 库 存 数量 为 : "+COMPUTER_NUMBER ) ; 


// 获 得 库存 数量 
public int getStockNumber(){ 
return COMPUTER_NUMBER ， 
} 
// 存 货 压力 大 了 ， 束 要 通知 采购 人 员 不 要 采购 ， 销 售 人 员 要 尽快 销售 
public void clearStock(){ 
System,.,out .println(" 清 理 存货 数量 
为 : "+COMPUTER_NUMBER ) ， 
super .mediator.execute("stock.clear"); 
} 


Le 


销售 管理 Sale 类 如 代码 清单 14-10 所 示 。 


代码 清单 14-10 修改 后 的 销售 管理 


public class Sale extends AbstractColleague { 

public Sale(AbstractMediator _mediator ){ 
super(_mediator ) ， 

} 

// 销 售 IBM 电 脑 

public void sellIBMComputer(int number){ 
super .mediator.execute("sale.sell", number); 
System.out.println(" 销 售 IBM 电 脑 "+number+" 人 台 ")， 


} 
// 反 馈 销 售 情 况 ，0~~100 变 化 ，0 代 表 根 本 就 没 人 买 ，100 代 表 非 常 畅销 ， 


个 址 二 个 
public int getSaleStatus()t{ 

Random rand = new 
Random(System.currentTimeMil]lis( )); 

int saleStatus = rand.nextInt(100); 

System.out.println("IBM 电 脑 的 销售 情况 
为 : "+saleStatus); 

return saleStatus,; 


} 
// 折 价 处 理 
public void offSale(){ 
super .mediator.execute("sale.offsell"); 
} 


D 


[| 


增加 了 中 介 者 ， 场 景 类 也 需要 小 小 的 改动 ， 如 代码 清单 14-11 所 


修 ° 


代码 清单 14-11 修改 后 的 场景 


public class Client { 
public static void main(String[] args) { 

AbstractMediator mediator = new Mediator(); 
// 采 购 人 员 采 购 电 脑 
System.out.printlin("------ 采购 人 员 采 购 电脑 -------- SS 
Purchase purchase = new Purchase(mediator); 
purchase.buyIBMcomputer(100); 
// 销 售 人 员 销 售 电脑 
System.out.printin("\n------ 销售 人 员 销 售 电脑 - - - - - - - - 


"); 
Sale Sale = new Sale(mediator); 
sale.sellIiBMComputer(1); 
// 库 房管 理 人 员 管 理 库存 
System.out.println("\n------ 库房 管理 人 员 清 库 处 理 - ----- 


Stock stock = new Stock(mediator); 
stock.clearStock(); 


在 场景 类 中 增加 了 一 个 中 介 者 ， 然 后 分 别传 递 到 三 个 同事 类 中 ， 
三 个 类 都 具有 相同 的 特性 ， 只 负责 处 理 自己 的 活动 (行为) ， 与 自己 
无 关 的 活动 就 丢 给 中 介 者 处 理 ， 程 序 运 行 的 结果 是 相同 的 。 从 项 目 设 
计 上 来 看 ， 加 入 了 中 介 者 ， 设 计 结构 清晰 了 很 多 ， 而 且 类 间 的 耦合 性 
大 大 减少 ， 代 码 质 量 也 有 了 很 大 的 提升 。 


在 多 个 对 象 依赖 的 情况 下 ， 通 过 加 入 中 介 者 角色 ， 取 消 了 多 个 对 
象 的 关联 或 依赖 关系 ， 减 少 了 对 象 的 耦合 性 。 


14.2 中 介 者 模式 的 定义 


中 介 者 模式 的 定义 为 : Define an object that encapsulates how a set of 
objects interact.Mediator promotes loose coupling by keeping objects from 
referring to each other explicitly,and it lets you vary their interaction 
independently. 用 一 个 中 介 对 象 封 装 一 系列 的 对 象 交 互 ， 中 介 者 使 各 对 
象 不 需要 显示 地 相互 作用 ， 从 而 使 其 三 合 松散 ， 而 且 可 以 独立 地 改变 
它们 之 间 的 交互 。) 


中 介 者 模式 通用 类 图 如 图 14-7 所 示 。 


Mediator Colleague 


Concrete Mediator 


图 14-7 中 介 者 模式 通用 类 图 


从 类 图 中 看 ， 中 介 者 模式 由 以 下 几 部 分 组 成 : 

e Mediator 抽象 中 介 者 角色 

抽象 中 介 者 角色 定义 统一 的 接口 ， 用 于 各 同事 角色 之 间 的 通信 。 
e Concrete Mediator 具体 中 介 者 角色 


具体 中 介 痢 角色 通过 协调 各 同事 角色 实现 协作 行为 ， 因 此 它 必 须 
依赖 于 各 个 同事 角色 。 


e Colleague 同事 角色 


每 一 个 同事 角色 都 知道 中 介 者 角色 ， 而 且 与 其 他 的 同事 角色 通信 
的 时 候 ， 一 定 要 通过 中 介 者 角色 协作 。 每 个 同事 类 的 行为 分 为 两 种 : 
种 是 同事 本 身 的 行为 ， 比 如 改变 对 象 本 身 的 状态 ， 处 理 自 己 的 行为 
等 ， 这 种 行为 叫做 自发 行为 (Self-Method) ， 与 其 他 的 同事 类 或 中 介 
者 没有 任何 的 依赖 ， 第 二 种 是 必须 依赖 中 介 者 才能 完成 的 行为 ， 叫 做 
依赖 方法 (Dep-Method) 。 


中 介 者 模式 比较 简单 ， 其 通用 源码 也 比较 简单 ， 先 看 抽象 中 介 者 
Mediator 类 ， 如 代码 清单 14-12 所 示 。 
代码 清单 14-12 通用 抽象 中 介 者 


public abstract class Mediator { 
// 定 义 同事 类 


protected ConcreteColleaguel1 ci1; 

protected ConcreteColleague2 c2; 

// 通 过 getter/setter 方 法 把 同事 类 注入 进来 

public ConcreteColleaguel1 getC1() { 
return ci1,; 


} 
public void setCi(ConcreteColleaguel1 c1) { 
this.c1i = ci1; 


} 
public ConcreteColleague2 getc2() { 
return c2; 


} 
public void setC2(ConcreteColleague2 c2) { 
this.c2 = c2; 


} 

// 中 介 者 模式 的 业务 逻辑 

Dupin abstract void doSomething1(); 
public abstract void doSomething2(); 


在 Mediator 抽 象 类 中 我 们 只 定义 了 同事 类 的 注入 ， 为 什么 使 用 同事 
实现 类 注入 而 不 使 用 抽象 类 注入 呢 ? 那 是 因为 同事 类 虽然 有 抽象 ， 但 
是 没 有 每 个 同事 类 必须 要 完成 的 业务 方法 ， 当 然 如 果 每 个 同事 类 都 有 
相同 的 方法 ， 比 如 execute、handler 等 ， 那 当然 注入 抽象 类 ， 做 到 依赖 
倒置 。 


具体 的 中 介 者 一 般 只 有 一 个 ， 即 通用 中 介 者 ， 其 源 代码 如 代码 清 
单 14-13 所 示 。 


代码 清单 14-13 通用 中 介 考 


public class ConcreteMediator extends Mediator { 
@Override 
public void doSomething1() { 
// 调 用 同事 类 的 方法 ， 只 要 是 public 方 法 都 可 以 调用 
super.c1.selfMethod1( ) ; 
Super.c2.SselfMethod2( ) ; 


public void doSomething2() { 
super.c1.selfMethod1(); 
super.c2.selfMethod2(); 


证 


中 介 者 所 具有 的 方法 doSomething1 和 doSomething2 都 是 比较 复杂 的 
业务 逻辑 ， 为 同事 类 服务 ， 其 实现 是 依赖 各 个 同事 类 来 完成 的 。 


同事 类 的 基 类 如 代码 清单 14-14 所 示 。 


代码 清单 14-14 抽象 同事 类 


public abstract class Colleague { 
protected Mediator mediator; 
public Colleague(Mediator _mediator ){ 


this.mediator = _mediator; 
} 
} 
这 个 基 类 也 非常 简单 。 一 般 来 说 ， 中 介 者 模式 中 的 抽象 都 比较 简 
单 ， 是 为 了 建立 这 个 中 介 而 服务 的 ， 具 体 同事 类 如 代码 清单 14-15 所 
未 3 


代码 清单 14-15 具体 同事 类 


public class ConcreteColleaguel1 extends Colleague { 
// 通 过 构造 函数 传递 中 介 者 
public ConcreteColleaguei(Mediator _mediator)t{ 
super(_mediator ); 
} 


// 自 有 方法 self-method 
public void selfMethod1( ){ 
// 处 理 自己 的 业务 逻辑 


} 
// 依 赖 方法 dep-method 
public void depMethod1(){ 


// 处 理 自 己 的 业务 逻辑 
// 自 己 不 能 处 理 的 业务 逻辑 ， 委 托 给 中 介 者 处 理 
super .mediator.doSomething1( ); 


} 


public class ConcreteColleague2 extends Colleague 1{ 
// 通 过 构造 画 数 传递 中 介 者 
public ConcreteColleague2(Mediator _mediator ){ 
super(_mediator ) ， 
} 


// 自 有 方法 self-method 
public void selfMethod2(){ 
// 处 理 自己 的 业务 逻辑 


} 

// 依 赖 方法 dep-method 

public void depMethod2(){ 
// 处 理 自己 的 业务 逻辑 
// 自 己 不 能 处 理 的 业务 逻辑 ， 委 托 给 中 介 者 处 理 
super .mediator.doSomething2(); 


为 什么 同事 类 要 使 用 构造 函数 注入 中 介 者 ， 而 中 介 者 使 用 
getter/setter 方 式 注入 同事 类 呢 ? 这 是 因为 同事 类 必须 有 中 介 者 ， 而 中 介 
者 却 可 以 只 有 部 分 同事 类 。 


14.3 中 介 者 模式 的 应 用 


14.3.1 中 介 者 模式 的 优点 


中 介 者 模式 的 优点 束 古 减少 类 间 的 依赖 ， 把 原 有 的 一 对 多 的 依赖 
变 成 了 一 对 一 的 依赖 ， 同 事 类 只 依赖 中 介 者 ， 减 少 了 依赖 ， 当 然 同时 
也 降低 了 类 间 的 耦合 。 


14.3.2 中 介 者 模式 的 缺 抬 


中 介 者 模式 的 缺点 束 是 中 介 痢 会 脱 胀 得 很 大 ， 而 且 逻 辑 复杂 ， 原 
本 N 个 对 象 直接 的 相互 依赖 关系 转换 为 中 介 者 和 同事 类 的 依赖 天 系 ， 
同事 类 越 多 ， 中 介 者 的 逻辑 束 越 复 灯 。 


14.3.3 中 介 痢 模式 的 使 用 场景 


中 介 者 模式 简单 ， 但 古 位 单 不 代表 容易 使 用 ， 很 容易 修 误 用 。 在 
面 辣 对 象 的 编程 中 ， 对 象 和 对 象 之 间 必 然 会 有 依赖 关系 ， 如 采 某 个 类 
和 其 他 类 没有 任何 相互 依赖 的 天 系 ， 那 这 个 类 吏 是 一 个 “孤岛 >， 在 项 
目 中 殊 没 有 存在 的 必要 了 ! 吏 像 是 某 个 人 如 采 永 远 独 立 生活 ， 与 任何 


人 都 没有 关系 ， 那 这 个 人 基本 上 束 算 是 野人 了 一 一 排除 在 人 类 这 个 定 
hs 


类 之 间 的 依赖 关系 是 必然 存在 的 ， 一 个 类 依赖 多 个 类 的 情况 也 是 
存在 的 ， 存 在 即 合理 ， 那 是 否 可 以 说 只 要 有 多 个 依赖 关系 吏 考 虑 使 用 
中 介 痢 模式 呢 ? 答案 是 否定 的 。 中 介 者 模式 未 必 能 帮 你 把 原本 次 乱 的 
逻辑 整理 得 清 清楚 楚 ， 而 且 中 介 者 模式 也 是 有 缺点 的 ， 这 个 缺点 在 使 
用 不 当时 会 被 放大 ， 比 如 原本 束 简 单 的 几 个 对 象 依 赖 天 系 ， 如 采 为 了 
使 用 模式 而 加 入 了 中 介 者 ， 必 然 导 致 中 介 者 的 逻辑 复杂 化 ， 因 此 中 介 
者 模式 的 使 用 需要 “量力 而 行 ”! 中 介 者 模式 适用 于 多 个 对 象 之 间 紧 密 
硝 合 的 情况 ， 紧 密 硝 合 的 标准 是 : 在 类 疼 中 出 现 了 蜘蛛 网 状 结构 。 在 
这 种 情况 下 一 定 要 考虑 使 用 中 介 者 模式 ， 这 有 利于 把 蜂 蛛 网 梳理 为 星 
型 结构 ， 使 原本 复杂 混乱 的 关系 变 得 清晰 简单 


14.4 中 介 者 模式 的 实际 应 用 


中 介 者 模式 也 叫做 调集 者 模式 ， 是 什么 意思 呢 ? 一 个 对 象 要 和 N 
多 个 对 象 交流 ， 束 像 对 象 间 的 战争 ， 很 混和 想 。 这 时 ， 需 要 加 入 一 个 中 
心 ， 所 有 的 类 都 和 中 心 交流 ， 中 心 说 起 么 处 理 束 怎么 处 理 ， 我 们 举 一 
些 在 开发 和 生活 中 经 常会 碰 到 的 例子 。 


e 机 场 调度 中 心 


大 家 在 每 个 机 场 都 会 看 到 有 一 个 “xx 机 场 调 度 中 心 ”， 它 吏 是 具体 
的 中 介 者 ， 用 来 调度 每 一 架 要 降落 和 起 飞 的 飞机 。 比 如 ， 某 以 飞机 
(同事 类 ) 飞 到 机 场 上 空 了 ， 就 询问 调度 中 心 〈 中 介 者 ) “我 是 否 可 以 
降落 ”以 及 “降落 到 哪个 跑道 "， 调 度 中心 (中 介 者 ) 查看 其 他 飞机 ( 同 
事 类 ) 情况 ， 然 后 通知 飞机 降落 。 如 果 没 有 机 场 调度 中 心 ， 飞 机 飞 到 
机 场 了 ， 飞 行 员 要 先 看 看 有 没有 飞机 和 目 己 一 起 降落 的 ， 有 没有 空 跑 
道 ， 俘 机 位 是 否 具备 等 情况 ， 这 种 局 面 是 难以 想象 的 ! 


e MVC 框 架 


大 家 都 应 该 使 用 过 Struts，MVC 框 架 ， 其 中 的 C (Controller) 就 是 
一 个 中 介 者 ， 叫 做 前 端 控制 絮 (Front Controller)， 它 的 作用 就 是 把 
M(Model， 业 务 逻 辑 ) 和 V (View， 视 图 ) 隔离 开 ， 协 调 M 和 VI 协同 工 


作 ， 把 M 运 行 的 结 末 和 V 代 表 的 视图 融合 成 一 个 前 端 可 以 展示 的 页 
面 ， 减 少 M 和 V 的 依赖 关系 。MVC 框 架 已 经 成 为 一 个 非常 流行 、 成 熟 
的 开发 框架 ， 这 也 是 中 介 者 模式 的 优点 的 一 个 体现 。 


e 媒体 网 关 


媒体 网 关 也 是 一 个 典型 的 中 介 者 模式 ， 比 如 使 用 MSN 时 ， 张 三 发 
消 思 给 李 四 ， 其 过 程 应 该 是 这 样 的 : 张 三 发 送 消 电 ，MSN 服 务 套 (中 介 
者 ) 接 收 到 消 轧 ， 碍 找 李 四 ， 把 消 妃 发 送 到 李 四 ， 同 时 通知 张 三 ， 消 妨 
已 经 发 送 。 在 这 里 ，MSN 服 务 吉 了 束 是 一 个 中 转 站 ， 负 责 协 调 两 个 客户 
端的 信息 交流 ， 与 此 相反 的 就 是 IPMsg 〈 也 叫 飞 鸽 ) ， 它 没有 使 用 中 
介 者 ， 而 直接 使 用 了 UDP 广播 的 方式 ， 每 个 客户 端 既是 客户 端 也 是 服 


现在 中 介 服 务 非 常 多 ， 比 如 租房 中 介 、 出 国 中 介 ， 这 些 也 都 是 中 
介 模 式 的 具体 体现 ， 比 如 你 去 租房 子 ， 如 有 果 没 有 房屋 中 介 ， 你 束 必 须 
一 个 一 个 小 区 去 找 ， 看 看 有 没有 空房 子 ， 有 没有 适合 目 己 的 房子 ， 找 
到 房子 后 还 要 和 房东 签 合约 ， 目 己 检查 房屋 的 家 具 、 水 电 煤 等 ， 有 了 
中 介 后 ， 你 束 省 心 多 了 ， 找 中 介 ， 然 后 安排 看 房子 ， 看 中 了 ， 签 合 
约 ， 中 介 帮 你 检查 房屋 家 具 、 水 电 煤 等 等 。 这 也 十 中 介 模 式 的 实际 应 
用 。 


14.5 最 佳 实践 


本 章 讲述 的 中 介 者 模式 很 少 用 到 接口 或 者 抽象 类 ， 这 与 依赖 倒置 
原则 是 冲突 的 ， 这 是 什么 原因 呢 ? 首先 ， 既 然 是 同事 类 而 不 是 兄弟 类 
《有 相同 的 血缘 ) ， 那 就 说 明 这 些 类 之 间 是 协作 关系 ， 完 成 不 同 的 任 
务 ， 处 理 不 同 的 业务 ， 所 以 不 能 在 抽象 类 或 接口 中 产 格 定义 同事 类 必 
须 具 有 的 方法 《从 这 点 也 可 以 看 出 继承 是 高 侵入 性 的 ) 。 这 是 不 合适 
的 ， 残 像 你 我 是 同事 ， 虽 然 我 们 大 家 都 是 绷 九 晚 五 地 上 班 ， 但 羡 你 跟 
我 干 的 活 肯 定 不 同 ， 不 可 能 抽象 出 一 个 父 类 统一 定义 同事 所 必须 有 的 
方法 。 当 然 ， 每 个 同事 都 要 吃饭 、 上 出 所， 可 以 把 这 些 最 基本 的 信息 
封 骏 到 抽象 中 ， 但 这 些 最 基本 的 行为 或 属性 是 中 介 者 模式 要 关心 的 
吗 ? 如 果 两 个 对 和 象 不 能 提炼 出 共性 ， 那 束 不 要 刻意 去 追求 两 者 的 抽 
象 ， 抽 象 只 要 定义 出 模式 需要 的 角色 即 可 。 当 然 如 采 严 格 人 遵守 面 疝 接 
口 编程 的 话 ， 则 是 需要 抽象 的 ， 这 束 需 要 读者 在 实际 开发 中 灵活 掌 
握 。 其 次 ， 在 一 个 项 目 中 ， 中 介 者 模式 可 能 被 多 个 模块 采用 ， 每 个 中 
介 者 所 围绕 的 同事 类 各 不 相同 ， 你 能 抽象 出 一 个 具有 共性 的 中 介 者 
吗 ? 不 可 能 ， 一 个 中 介 者 抽象 类 一 般 只 有 一 个 实现 者 ， 除 非 中 介 者 逻 
辑 非 常 复杂 ， 代 码 量 非常 大 ， 这 时 才 会 出 现 多 个 中 介 者 的 情况 。 所 
以 ， 对 于 中 介 者 来 说 ， 抽 象 已 经 没有 太 多 的 必要 。 


中 介 痢 模式 是 一 个 非常 好 的 封 痛 模 式 ， 也 是 一 个 很 容易 被 瀣 用 的 
模式 ， 一 个 对 象 依赖 儿 个 对 象 是 再 正 稼 不 过 的 事情 ， 但 是 纯 理 论 家 丈 
会 要 求 使 用 中 介 痢 模式 来 封闭 这 种 依赖 和 关系， 这 是 非常 危险 的 ! 使 用 
中 介 模 式 束 必然 会 带 来 中 介 者 的 膨胀 问题 ， 这 在 一 个 项 目 中 十 很 不 恰 
当 的 。 大 家 可 以 在 如 下 的 情况 下 竹 试 使 用 中 介 者 模式 : 


e N 个 对 象 之 间 产 生 了 相互 的 依赖 关系 (N>2) 。 


e 多 个 对 象 有 依赖 和 关系， 但 是 依赖 的 行为 疝 不 确定 或 者 有 发 生 改 
变 的 可 能 ， 在 这 种 情况 下 一 般 建议 采用 中 介 者 模式 ， 降 低 变 更 引起 的 
风险 扩散 。 


e 产品 开发 。 一 个 明显 的 例子 束 是 MVC 框 腰 ， 把 中 介 者 模式 应 用 
到 产品 中 ， 可 以 提升 产品 的 性 能 和 扩展 性 ， 但 是 对 于 项 目 开 发 瓯 未 
必 ， 因 为 项 目 是 以 交付 投产 为 目标 ， 而 产品 则 是 以 稳定 、 高 效 、 扩 展 


为 未 由。 


aa 
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15.1 项 目 经 理 也 难当 


我 是 公司 的 项 目 经 理 ， 在 国内 做 项 目 ， 项 目 经 理 需 要 什么 都 懂 ， 
什么 都 管 。 做 好 了 ， 项 目 经 理 能 分 到 一 杯 北 ;做 不 好 ， 都 是 项 目 经 理 
的 责任 。 这 几乎 是 绝对 的 ， 我 市 过 很 多 项 目 ， 行 政 命令 一 压 下 来 ， 那 
忠 一 条 道 ， 做 完 做 好 ! 


虽然 我 们 公司 是 一 个 集团 公司 ， 但 是 我 们 部 门 的 业绩 是 独立 核算 
的 ， 也 就 是 说 ， 我 们 部 门 不 仅 可 以 为 集团 公司 服务 ， 还 可 以 为 其 他 甲 
方 服 务 ， 赚 取 更 多 的 外 快 。2007 年 ， 我 曾 负责 一 个 比较 小 的 项 目 〈 但 
征 项 目的 合同 金额 可 不 少 ) 一 一 为 某 家 旅行 社 建立 一 套 内 部 管理 系 
统 。 该 旅行 社 的 门店 比较 多 ， 员 工 也 比较 多 ， 这 个 内 部 管理 系统 用 来 
管理 和 客户、 旅游 货源 、 票 务 以 及 内 部 事务 ， 人 整体 上 类 似 于 一 个 小 型 的 
MIS 系 统 。 客 户 的 需求 比较 明确 ， 因 为 他 们 曾经 自己 购买 了 一 套 内 部 管 
理 系统 ， 这 次 变动 基本 上 走 翻 版， 而且 这 家 旅行 社 也 有 目 己 的 IT 部 
门 ， 技 术 人 员 之 间 语 言 相 通 ， 比 较 好 相处 ， 也 没有 交流 鸿沟 。 


该 项 目的 成 员 分 工 采 用 了 常规 的 分 工 方式 ， 分 为 需求 组 
(Requirement Group,RG) 、 美 工 组 (Page Group,PG) 、 代 码 组 (我 
们 内 部 还 有 一 个 比较 优雅 的 名 字 : 逻辑 实现 组 ， 这 里 使 用 大 家 经 常 称 


呼 的 名 称 ， 即 Code Group ， 简 称 CG) ， 加 上 我 这 个 项 目 经 理 正 好 十 个 
人 。 刚 开始 ， 客 户 〈 也 就 是 旅行 社 ， 甲 方 ) 很 乐意 和 我 们 每 个 组 探 

讨 ， 比 如 和 需求 组 讨论 需求 、 和 美工 讨论 页 面 、 和 代码 组 讨论 实现 ， 

告诉 他 们 修改 、 删 除 、 增 加 各 种 内 容 等 。 这 是 一 种 比较 常见 的 甲乙 方 
合作 模式 ， 甲 方 深入 到 乙方 的 项 目 开发 中 ， 我 们 可 以 使 用 类 图 来 表示 
这 个 过 程 ， 如 图 15-1 所 示 。 


+void find() 
+void aadadl() 


+void delete() 
+void changel) 
tvoid plan() 


CodeGroup 


图 15-1 旅行 社 项 目 开发 过 程 类 图 


这 个 类 图 很 商 单 ， 客 记 和 三 个 组 都 有 交流 ， 这 也 合情合理 。 那 我 
们 看 看 这 个 过 程 的 实现 ， 首 先 看 抽象 类 Group， 如 代码 清单 15-1 所 示 。 


代码 清单 15-1 抽象 组 


public abstract class Group { 
// 甲 乙 双 方 分 开办 公 ， 如 果 你 要 和 某 个 组 讨论 ， 你 首先 要 找到 这 个 组 
public abstract void find(); 
// 被 要 求 增加 功能 
public abstract void add() ， 
// 被 要 求 删除 功能 
public abstract void delete(); 
// 被 要 求 修 改 功能 
public abstract void change(); 
// 被 要 求 给 出 所 有 的 变更 计划 


public abstract void plan(); 


大 家 看 抽象 类 中 的 每 个 方法 ， 其 中 的 每 个 都 是 一 个 命令 语气 
一 一 “找到 它 ， 增 加 ， 删 除 ， 给 我 计划 ! ”这些 都 是 命令 ， 给 出 命令 然 
后 由 相关 的 人 员 去 执行 。 我 们 再 看 3 个 实现 类 ， 其 中 的 需求 组 最 重要 ， 
需求 组 RequirmentGroup 类 如 代码 清单 15-2 所 示 。 


代码 清单 15-2 需求 组 


public class RequirementGroup extends Group { 
// 客 户 要 求 需 求 组 过 去 和 他 们 谈 
public void find() { 
System.out.println(" 找 到 需求 组 .,.")， 
} 


// 客 户 要 求 增加 一 项 需求 

public void add() { 
System.out.println(" 客 户 要 求 增 加 一 项 需求 ..."); 

} 


// 客 户 要 求 修改 一 项 需求 
public void change() { 
System.out.println(" 客 户 要求 修 改 一 项 需求 . . ."); 


} 

// 客 户 要 求 删除 一 项 需求 

public void delete() { 
System.out.println(" 客 户 要求 删 除 一 项 需求 . , ,"); 

} 


// 客 户 要 求 给 出 变更 计划 

public void plan() { 
System.out.println(" 客 户 要 求 需求 变更 计划 ,,."); 

} 


需求 组 有 了 ， 我 们 再 看 美工 组 。 美 工 组 也 很 重要 ， 是 项 目的 脸 
面 ， 客 户 最 终 接触 到 的 还 是 界面 。 美 工 组 PageGroup 类 如 代码 清单 15-3 
所 示 。 


代码 清单 15-3 美工 组 


public class Se eo extends Group { 
// 首 先 这 个 美工 组 应 该 能 找到 吧 ， 要 不 你 跟 谁 谈 ? 
public void find() { 
System.out.println(" 找 到 美工 组 . ,.")， 


} 
// 美 工 被 要 求 增加 一 个 页 面 
public void add() { 

System.out .println(" 客 户 要 求 增加 一 个 页 面 .， 
} 


// 客 户 要 求 对 现 有 界面 做 修改 
public void change() { 
System.out.println(" 客 户 要 求 修改 一 个 页 面 .. 


} 

// 甲 方 是 老大 ， 要 求 删 除 一 些 页 面 

public void delete() { 
System.out.println(" 客 户 要 求 删 除 一 个 页 面 .. 


} 

// 所 有 的 增 、 删 、 改 都 要 给 出 计划 

public void plan() { 
System.out.println(" 客 户 要 求 页 钙 

} 
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变更 计划 ..."); 


最 后 看 代码 组 。 这 个 组 的 成 员 一 般 比 较 沉 问 ， 不 多 说 话 ， 但 多 做 
事 儿 ， 这 是 这 个 组 的 典型 特点 。 代 码 组 CodeGroup 类 如 代码 清单 15-4 所 


修 ° 


代码 清单 15-4 代码 组 


public class CodeGroup extends Group { 
// 客 户 要 求 代 码 组 过 去 和 他 们 谈 
public void find() { 
System.out.println(" 找 到 代码 组 ,,.")， 


} 

// 客 户 要 求 增加 一 项 功能 

public void add() { 
System.out.println(" 客 户 要 求 增 加 一 项 功能 ..."); 


} 

// 客 户 要 求 修 改 一 项 功能 

public void change() { 

System.out .println(" 客 户 要 求 修改 一 项 功能 ,.,.")，; 


} 

// 客 户 要 求 删除 一 项 功能 

public void delete() { 

System.out.println(" 客 户 要 求 删 除 一 项 功能 ..."); 


} 

// 客 户 要 求 给 出 变更 计划 

public void plan() { 
System.out.println(" 客 户 要求 代 码 变更 计划 ..."); 


整个 项 目的 3 个 支柱 都 已 经 产生 了 ， 那 看 客户 怎么 和 我 们 谈 。 客 户 
刚 开始 提 交 了 他 们 自己 写 的 一 份 比较 完整 的 需求 ， 需 求 组 根据 这 份 需 
求 写 了 一 份 分 析 说 明 书 ， 客 户 看 后 ， 要 求 增加 需求 ， 该 场景 如 代码 清 
单 15-5 所 示 。 


代码 清单 15-5 场景 


public class Client { 
public static void main(String[] args) { 
// 首 先 客户 找到 需求 组 说 ， 过 来 谈 需 求 ， 并 修改 
System out ,println("----------- 客 户 要 求 增 加 一 项 需求 - - - 


Group rg = new RequirementGroup(); 
// 找 到 需求 组 

rg.find(); 

// 增 加 一 个 需求 

rg.add( ); 

// 要 求 变更 计划 

rg.plan(); 


证 


运行 的 结 末 如 下 所 示 : 


ee 客户 要 求 增加 一 项 需求 --…----…------ 


找到 需求 组 … 


客户 要 求 增加 一 项 需求 . 


客户 要 求 需求 变更 计划 .. 


客户 的 需求 暂时 满足 了 ， 过 了 一 段 时 间 ， 客 户 又 要 求 “界面 多 画 了 
过 来 谈 谈 ”"， 于 十 义 有 一 次 场景 变化 ， 如 代码 清单 15-6 所 示 。 


代码 清单 15-6 变化 的 场景 


public class Client { 
public static void main(String[] args) St 
// 首 先 客户 找到 美工 组 说 ， 过 来 谈 页 面 ， 并 修改 
System. out. println("---------- 客 户 要 求 删除 一 个 页 面 - - - - 


Group pg = new PageGroup( ) ， 
// 找 到 需求 组 

pg.find() 

// 删 除 一 项 需求 

pg,delete()， 

// 要 求 变 更 计划 


pg.plan(); 


a 客户 要 求 删 除 一 个 页 面 ----------------- 


客户 要 求 删 除 一 个 页 面 .… 


客户 要 求 页 面 变 更 计划 .… 


好 了 ， 界 面 也 谈 过 了 ， 应 该 没什么 大 问题 了 吧 。 过 了 一 天 后 ， 客 
户 又 让 代码 组 过 去 ， 说 是 数据 库 设计 问题 ， 然 后 又 叫 美工 组 过 去 ， 布 
置 了 一 堆 命 令 .…… 这 个 束 不 一 一 号 了 ， 大 家 应 该 能 够 体会 得 到 ! 问题 
来 了 ， 我 们 修改 可 以 ， 但 是 每 次 都 是 叫 一 个 组 去 ， 布 置 个 任务 ， 然 后 
出 计划 ， 每 次 部 这 样 ， 如 琳 让 你 当 甲 方 ， 你 烦 不 烦 ? 而 且 这 种 方式 很 
容易 出 错误 ， 并 且 还 真 发 生 过 。 客 户 把 美工 叫 过 去 了， 要 删除 ， 可 美 
工 说 需求 是 这 么 写 的 ， 然 后 客户 又 命令 需求 组 过 去 ， 一 次 次 地 折腾 之 
后 ， 客 户 也 烦躁 了 ， 于 是 直接 抓 住 我 这 个 项 目 经 理 说 :“ 我 不 管 你 们 内 
部 怎么 安排 ， 你 惑 给 我 找 个 接头 负责 人 ， 我 告诉 他 怎么 做 ， 删 除 页 
面 ， 增 加 功能 ， 你 们 内 部 怎么 处 理 我 不 管 ， 我 就 告诉 他 我 要 干什么 就 


我 一 听 ， 好 啊 ， 这 也 正 是 我 想 要 的 ， 我 们 项 目 组 的 兄 们 也 已 经 
受 不 了 了 ， 于 是 我 改变 了 一 下 我 的 处 理 方式 ， 如 图 15-2 所 示 。 


Invoker 
Eee 


+vold setCommand(String str) 
Hvoid Action() 


Client 


+void find() 
+void add() 


+void delete() 
t+void changel() 
+void plan() 


CodeGroup PageGroup RequirementGroup 
[Ce -一 一 一 一 es=== = 
[A 

| | [| | 


图 15-2 增加 人 负责 人 后 的 类 图 


在 原 有 的 类 图 上 增加 了 一 个 Invoker 类 ， 其 作用 是 根据 客户 的 命令 
安排 不 同 的 组 员 进 行 工 作 ， 例 如 ， 客 户 说 “界面 上 删除 一 条 记录 ”， 
Invoker 类 接收 到 该 String 类 型 命令 后 ， 通 知 美 工 组 PageGroup 开 始 
delete， 然 后 ee 台 不 要 存 到 数据 库 中 ， 最 后 肥 
馈 给 客户 一 个 执行 计划 。 这 是 一 个 挺 好 的 方案 ， 但 是 客户 的 命令 
个 String 类 型 的 ， 这 有 非常 多 的 变化 ， 仅 仅 通过 一 个 字符 串 来 传递 命令 
并 不 是 一 个 非常 好 的 方案 ， 因 为 在 系统 设计 中 ， 字 符 串 没有 约束 力 ， 


四 
人 三 


根据 字符 串 判 断 相 关 的 业务 逻辑 不 是 一 个 优秀 的 解决 方案 。 那 怎么 才 
征 一 个 优秀 的 方案 呢 ? 解决 方案 是 : 对 客户 发 出 的 命令 进行 封装 ， 
个 命令 是 一 个 对 象 ， 避 免 客户 、 负 责 人 、 组 员 之 间 的 交流 误差 ， 封 装 
后 的 结果 就 是 客户 只 要 说 一 个 命令 ， 我 的 项 目 组 束 立 刻 开 始 启动 ， 不 
思考 、 解 析 命 信子 符 串 ， 如 图 15-3 所 示 。 
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+void final() 
+void adal) 


+void delete() 
+void changel() 
+void plan() 
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#RequirementGroup rg = new RequirementGroup() 
#PageGroup pg = new PageGroup() 

#CodeGroup cg = new CodeGroup() 
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DeletePageCommand 
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图 15-3 完美 的 类 图 


Command 抽 象 类 只 有 一 个 方法 execute， 其 作用 就 是 执行 命令 ， 子 
类 非常 坚决 地 实现 该 命令 ， 与 军队 中 类 似 ， 上 级 军官 给 士兵 发 布 命 
令 : 上 这 个 旗杆 ! 然后 士兵 回答 : Yes,Sir! 完美 的 项 目 也 与 此 类 似 ， 
客户 发 送 一 个 删除 页 面 的 命令 ， 接 头 负责 人 Invoker 接 收 到 命令 后 ， 立 
刻 执 行 DeletePageCommand 的 execute 方 法 。 对 类 图 中 增加 的 几 个 类 说 明 
如 下 。 


e Command 抽 象 类 : 客户 发 给 我 们 的 命令 ， 定 义 三 个 工作 组 的 成 
员 变 量 ， 供 子 类 使 用 ， 定 义 一 个 抽象 方法 execute， 由 子 类 来 实现 。 


e CInvoker 实 现 类 : 项 目 接头 负责 人 ，setComand 接 收 客户 发 给 我 
们 的 命令 ，action 方 法 是 执行 客户 的 命令 (方法 名 写成 是 action， 与 


command 的 execute 区 人 分开， 避免 混 消 ) 。 


其 中 ，Command 抽 象 类 是 整个 扩展 的 核心 ， 其 源 代码 如 代码 清单 
15-7 所 示 。 


代码 清单 15-7 抽象 命令 类 


public abstract class Command { 
// 把 三 个 组 都 定义 好 ， 子 类 可 以 直接 使 用 
protected RequirementGroup rg = new RequirementGroup(); // 
需求 组 
protected PageGroup pg = new PageGroup(); // 美 工 组 
protected CodeGroup cg = new CodeGroup(); // 代 码 组 
// 只 有 一 个 方法 ， 你 要 我 做 什么 事情 


共 


public abstract void execute() ; 


抽象 类 很 简单 ， 具 体 的 实现 类 只 要 实现 execute 方 法 就 可 以 了 。 在 
一 个 项 目 中 ， 需 求 增加 是 很 常见 的 ， 那 就 把 < 增加 需求 ”定义 为 一 个 命 
令 AddRequirementCommand 类 ， 如 代码 清单 15-8 所 示 。 


代码 清单 15-8 增加 需求 的 命令 


public class AddRequirementCommand extends Command { 
// 执 行 增加 一 项 需求 的 命令 
public void execute() { 
// 找 到 需求 组 
super .rg.find(); 
// 增 加 一 份 需求 
super.rg.add( ); 
// 给 出 计划 
super.rg.plan(); 


页 面 变更 也 是 比较 频 党 发 生 的， 定义 一 个 删除 页 面 的 命令 
DeletePageCommand 类 ， 如 代码 清单 15-9 所 示 。 


代码 清单 15-9 删除 页 面 的 命令 


public class DeletePageCcommand extends Command { 

// 执 行 删除 一 个 页 面 的 命令 

public void execute() { 
// 找 到 页 面 组 
super .pg.find(); 
// 删 除 一 个 页 面 
super.rg.delete( ); 
// 给 出 计划 
super.rg.plan(); 


Command 抽 象 类 可 以 有 N 个 子 类 ， 如 增加 一 个 功能 命令 
(AddFunCommand) ， 删 除 一 份 需求 命令 
(DeleteRequirementCommand) 等 ， 这 里 就 不 再 描述 了 ， 只 要 是 由 客 

户 产生 、 时 常 性 的 行为 都 可 以 定义 为 一 个 命令 ， 其 实现 类 都 比较 简 
单 ， 读 者 可 以 目 行 扩展 。 


客户 发 送 的 命令 已 经 确定 下 来 ， 我 们 再 看 负责 人 Invoker， 如 代码 
清单 15-10 所 示 。 


代码 清单 15-10 负责 


public class Invoker { 
// 什 么 命令 
private Command command ; 
// 客 户 发 出 命令 
public void setCommand(Command command){ 
this.command = command; 


} 

// 执 行 客户 的 命令 

public void action(){ 
this.command.execute( ); 

} 


这 更 简单 了 ， 负 责 人 只 要 接 到 客户 的 命令 ， 就 立刻 执行 。 我 们 模 
拟 增加 一 项 需求 的 过 程 ， 如 代码 清单 15-11 所 示 。 


代码 清单 15-11 增加 一 项 需求 


public class Client { 
public static void main(String[] args) { 
// 定 义 我 们 的 接头 人 
Invoker xiaoSan = new Invoker(); // 接 头 人 就 是 小 三 
// 客 户 要 求 增 加 一 项 需求 


System,out,.println("------------ 客 户 要 求 增加 一 项 需求 - - 
ee 由 ) 

// 客 户 给 我 们 下 命令 来 

Command command = new AddRequirementCommand(); 

// 接 头 人 接收 到 命令 

xiaoSan.setCommand(command); 

// 接 头 人 执行 命令 


xiaoSan.action(); 


} 
} 
运行 结果 如 下 所 示 : 
二 客户 要 求 增加 一 项 需求 ----------------- 
找到 需求 组 


客户 要 求 增加 一 项 需求. 


客户 要 求 需求 变更 计划 .… 


征 不 是 我 们 的 场景 类 简单 了 很 多 ? 客户 只 要 给 命令 ， 我 马上 的 
本。 简单 ! 非常 简单 ! 那 我 们 看 看 ， 如 采 客 户 要 求 删 除 一 个 页 面 ， 我 
们 的 修改 有 多 大 ， 如 代码 清单 15-12 所 示 。 


代码 清单 15-12 删除 一 个 页 面 


public class Client { 
public static void main(String[] args) { 
// 定 义 我 们 的 接头 人 
Invoker xiaoSan = new Invoker(); // 接 头 人 就 是 小 三 
// 客 户 要 求 增 加 一 项 需求 
System.out .println("------------ 客 户 要求 删 除 一 个 页 面 
Sd ")s 
// 客 户 给 我 们 下 命令 来 
//Command command = new AddReduirementCommand ( ) ， 
Command command = new DeletePageCcommand ( ) ， 
// 接 头 人 接收 到 命令 
xiaoSan.setCommand(command); 


// 接 头 人 执行 命令 


xiaoSan.action(); 


证 


Re 客户 要 求 删 除 一 个 页 面 ---------------- 


找到 美工 组 .… 
客户 要 求 删除 一 项 需求 .… 


客户 要 求 需求 变更 计划 .… 
看 到 上 面 用 狙 体 显 示 的 代码 了 吗 ? 只 修改 了 这 么 多 ， 是 不 是 很 商 
单 ， 而 且 客户 也 不 用 知道 到 抵 由 谁 来 修改 ， 高 内 聚 的 有 要求 体现 出 来 


了 ， 这 束 是 命令 模式 。 


15.2 命令 模式 的 定义 


命令 模式 是 一 个 高 内 聚 的 模式 ， 其 定义 为 :Encapsulate a request as 
an object,thereby letting you parameterize clients with different 
requests,queue or log requests,and support undoable operations. (将 一 个 请 
求 封 闭 成 一 个 对 象 ， 从 而 让 你 使 用 不 同 的 请 求 把 客户 端 参 数 化 ， 对 请 
求 排队 或 者 记录 请 求 日 志 ， 可 以 提供 命令 的 撤销 和 恢复 功能 。) 


命令 模式 的 通用 类 图 如 图 15-4 所 示 。 


Command 


+Execute() 


Receiver 


+Action() 


>、 


图 15-4 命令 模式 的 通用 类 图 


在 该 类 图 中 ， 我 们 看 到 三 个 角色 : 


e Receive 接 收 者 角色 


该 角色 束 是 干 活 的 角色 ， 命 令 传递 到 这 里 是 应 该 被 执行 的 ， 具 体 
到 我 们 上 面 的 例子 中 就 是 Group 的 三 个 实现 类 。 


e Command 命 令 角 色 
需要 执行 的 所 有 命令 都 在 这 里 声明 。 
e Invoker 调 用 者 角色 


接收 到 命令 ， 并 执行 命令 。 在 例子 中 ， 我 〈 项 目 经 理 ) 就 是 这 个 
角色 。 


命令 模式 比较 简单 ， 但 是 在 项 目 中 非常 频繁 地 使 用 ， 因 为 它 的 示 
装 性 非常 好 ， 把 请 求 方 (Invoker) 和 执行 方 (Receiver) 分 开 了 ， 扩 展 
性 也 有 很 好 的 保障 ， 通 用 代码 比较 简单 。 我 们 先 阅读 一 下 Receiver 类 ， 
如 代码 清单 15-13 所 示 。 


代码 清单 15-13 通用 Receiver 类 


public abstract class Receiver { 
// 抽 象 接收 者 ， 定 义 每 个 接收 者 都 必须 完成 的 业务 
public abstract void doSomething(); 


} 


很 奇怪 ， 为 什么 Receiver 是 一 个 抽象 类 ? 那 是 因为 接收 者 可 以 有 多 
个 ， 有 多 个 就 需要 定义 一 个 所 有 特性 的 抽象 集合 一 一 抽象 的 接收 者 ， 
其 具体 的 接收 羞 如 代码 清单 15-14 所 示 。 


代码 清单 15-14 具体 的 Receiver 类 


public class ConcreteReciver1 extends Receivert{ 
// 每 个 接收 者 都 必须 处 理 一 定 的 业务 逻辑 
public void doSomething(){ 
} 


public class ConcreteReciver2 extends Receivert{ 
// 每 个 接收 者 都 必须 处 理 一 定 的 业务 逻辑 
public void doSomething( ){ 
} 


接收 着 可 以 是 N 个 ， 这 要 依赖 业务 的 具体 定义 。 命 令 角 色 是 命令 模 
式 的 核心 ， 其 抽象 的 命令 类 如 代码 清单 15-15 所 示 。 


代码 清单 15-15 抽象 的 Command 类 


public abstract class Command { 
// 每 个 命令 类 都 必须 有 一 个 执行 命令 的 方法 
public abstract void execute() ; 


根据 环境 的 需求 ， 具 体 的 命令 类 也 可 以 有 N 个 ， 其 实现 类 如 代码 清 
单 15-16 所 示 。 


代码 清单 15-16 具体 的 Command 类 


public class ConcreteCommand1 extends Command { 
// 对 哪个 Receiver 类 进行 命令 处 理 
private Receiver receiver; 
// 构 造 钞 数 传递 接收 者 
public ConcreteCommand1i(Receiver _receiver)t{ 
this.receiver = _receiver; 


} 

// 必 须 实现 一 个 命令 

public void execute() { 
// 业 务 处 理 


this.receiver.doSomething(); 


} 


public class ConcreteCommand2 extends Command { 


// 哪 个 Receiver 类 进行 命令 处 理 

private Receiver recelver ; 

// 构 造 钞 数 传递 接收 者 

public ConcreteCommand2(Receiver _receiver)t{ 
this.receiver = _receiver; 


} 

// 必 须 实现 一 个 命令 

public void execute() { 
// 业 务 处 理 
this.receiver.doSomething(); 


定义 了 两 个 具体 的 命令 类 ， 读 者 可 以 在 实际 应 用 中 扩展 该 命令 
类 。 在 每 个 命令 类 中 ， 通 过 构 千 函数 定义 了 该 命令 是 针对 哪 一 个 接收 


首发 出 的 ， 定 义 一 个 命令 接收 的 主体 。 调 用 考 非 党 简单 ， 仪 实现 命令 
的 传递 ， 如 代码 清单 15-17 所 示 。 


代码 清单 15-17 调用 者 Invoker 类 


public class Invoker { 


private Command command ; 

// 受 气 包 ， 接 受命 令 

public void setCommand(Command _command)t{ 
this.command = _command; 


} 

// 执 行 命令 

public void action(){ 
this.command.execute( ); 

} 


调用 者 束 像 是 一 个 受气 包 ， 不 管 什么 命令 ， 都 要 接收 、 执 行 ! 那 


我 们 来 看 高 层 模块 如 何 调用 命令 模式 ， 如 代码 清单 15-18 所 示 。 


代码 清单 15-18 场景 


public class Client { 
public static void main(String[] args) { 


// 首 先 声 明 调用 者 Invoker 
Invoker invoker = new Invoker(); 
// 定 义 接 收 者 


Receiver receiver = new ConcreteReciver1(); 

// 定 义 一 个 发 送 给 接收 者 的 命令 

Command command = new ConcreteCommandi(receiver); 
// 把 命令 交 给 调用 者 去 执行 

invoker.setCommand(command); 

invoker .action(); 


一 个 完整 的 命令 模式 束 此 完成 ， 读 者 可 以 在 此 基础 上 进行 扩展 。 


15.3 命令 模式 的 应 用 
15.3.1 命令 模式 的 优点 


。 类 则 解 类 


调用 者 角色 与 接收 者 角色 之 间 没 有 任何 依赖 关系 ， 调 用 者 实现 功 
能 时 只 需 调 用 Command 抽 象 类 的 execute 方 法 就 可 以 ， 不 需要 了 解 到 底 
是 哪个 接收 者 执行 。 


e 可 扩展 性 


Command 的 子 类 可 以 非常 容易 地 扩展 ， 而 调用 者 Invoker 和 高 层次 
的 模块 Client 不 产生 严重 的 代码 耦合 。 


e 命令 模式 结合 其 他 模式 会 更 优秀 
命令 模式 可 以 结合 责任 链 模式 ， 实 现 命令 族 解 析 任 务 ; 结合 模板 


方法 模式 ， 则 可 以 减少 Command 子 类 的 膨胀 问题 。 


15.3.2 信念 模式 的 局所 


命令 模式 也 是 有 缺点 的 ， 请 看 Command 的 子 类 : 如 果 有 N 个 命 
令 ， 问 题 台 出 来 了 ，Command 的 子 类 束 可 不 是 儿 个 ， 而 是 N 个 ， 这 个 
类 脱 胀 得 非常 大 ， 这 个 号 需要 读者 在 项 目 中 慎重 考虑 使 用 。 


15.3.3 命令 模式 的 使 用 场景 


只 要 你 认为 古 命令 的 地 方 束 可 以 采用 命令 模式 ， 例如， 在 GUI 开 
发 中 ， 一 个 按钮 的 总 击 是 一 个 命令 ， 可 以 采用 命令 模式 ;模拟 DOS 命 
令 的 时 候 ， 当 然 也 要 采用 命令 模式 ; 触发 一 反馈 机 制 的 处 理 等 。 


15.4 命令 模式 的 扩展 


15.4.1 未 讲 完 的 故事 


上 面 的 例子 我 们 还 没有 说 完 。 想 想 看 ， 客 户 要 求 增加 一 项 需求 ， 
那 是 不 是 页 面 也 增加 ， 同 时 功能 也 要 增加 呢 ? 如 果 不 使 用 命令 模式 ， 
客户 就 需要 先 找 需求 组 ， 然 后 找 美 工 组 ， 再 找 代 码 组 .………. 你 想 让 客户 
跳楼 啊 ! 使 用 命令 模式 后 ， 客 户 只 管 发 命令 模式 ， 例 如 ， 需 要 增加 一 
项 需求 ， 没 问题 ， 我 内 部 调动 三 个 组 通力 合作 ， 然 后 把 结果 反馈 给 
你 ， 这 也 正 是 客户 需要 的 。 那 这 个 要 怎么 修改 呢 ? 想 想 看 ， 很 简单 
的 ! 在 AddRequirementCommand 类 的 execute 方 法 中 增加 对 PageGroup 
和 CodePage 的 调用 就 可 以 了 ， 修 改 后 的 代码 如 代码 清单 15-19 所 示 。 


代码 清单 15-19 修改 后 的 增加 需求 


public class AddRequirementCommand extends Command { 

// 执 行 增加 一 项 需求 的 命令 

public void execute() { 
// 找 到 需求 组 
super.rg.find(); 
// 增 加 一 份 需求 
super.rg.add(); 
// 页 面 也 要 增加 
super .pg.add(); 
// 功 能 也 要 增加 
super.cg.add(); 
// 给 出 计划 
super.rg.plan( ); 


看 看 ， 是 不 是 解决 问题 了 ? 客户 Client 只 需要 发 布 命令 ， 至 于 如 何 
执行 这 个 命 仿 ， 是 协调 一 个 对 象 ， 还 十 两 个 对 象 ， 都 不 需要 关心 ， 命 
令 模 式 做 了 一 层 非 党 好 的 封 狠 。 


15.4.2 反悔 问题 


我 们 的 例子 说 到 这 里 是 不 是 应 该 真 的 结束 了 ? 不 ， 还 有 一 个 问题 
会 经 芝 发 生 的 : 客户 发 出 命令 ， 要 撤回 ， 怎 么 办 ? 束 类 似 你 使 用 Ctl+Z 
组 合 键 《undo 功 能 ) ， 发 出 一 个 命令 ， 在 没有 执行 (这 时 只 要 重新 
setCommand 就 可 以 了 ) 或 执行 后 撤回 (执行 后 撤回 是 状态 变更 ;该 怎 
么 实现 呢 ? 


有 两 种 方法 可 以 解决 :一 是 结合 备 起 隶 模式 还 原 最 后 状态 ， 该 方 
法 适合 接收 者 为 状态 的 变更 情况 ， 而 不 适合 事件 处 理 ; 二 有 是 通过 增加 
一 个 新 的 命令 ， 实 现 事 件 的 回 滚 。 例 子 中 的 “删除 一 个 页 面 ? 束 需 要 一 
个 反 命令 ， 撤销 刚刚 删除 页 面 的 命令 ， 那 客户 发 出 这 样 一 个 命令 ,我 
们 该 怎么 处 理 呢 ? 


我 们 这 样 思考 ， 反 命令 也 坪 一 个 命令 ， 那 就 是 Command 的 一 个 于 
类 ， 它 实现 的 功能 就 是 恢复 刚刚 删除 的 页 面 ， 然 后 我 们 再 思考 ， 谁 能 
恢复 删除 的 页 面 呢 ? 当然 是 页 面 组 了 ， 于 有 是 作为 接收 者 的 页 面 组 必须 


还 有 一 个 方法 恢复 最 后 删除 的 页 面 ， 也 就 是 日 志 的 回访 机 制 了 ， 指 定 
一 个 页 面 ， 回 深 回 去 。 分 析 完 毕 ， 我 们 来 看 实现 ， 注 意 : 以 下 为 示意 
代码 ， 请 读者 目 行 在 应 用 中 进行 实现 。 修 正 后 的 Group 如 代码 清单 15- 
20 所 示 。 


代码 清单 15-20 修改 后 的 Group 类 


public abstract class Group { 
// 甲 乙 双 方 分 开办 公 ， 你 要 和 那个 组 讨论 ， 你 首先 要 找到 这 个 组 
public abstract void find(); 
// 被 要 求 增 加 功能 
public abstract void add(); 
// 被 要 求 删除 功能 
public abstract void delete(); 
// 补 要 求 修改 功能 
public abstract void change( ); 
// 钼 要 求 给 出 所 有 的 变更 计划 
public abstract void plan(); 
// 每 个 接收 者 都 要 对 直接 执行 的 任务 可 以 回 深 
public void rollBack( ){ 
// 根 据 日 志 进 行 回 深 
} 


仅仅 增加 了 一 个 rollBack 的 方法 ， 每 个 接收 者 都 可 以 对 上 自己 实现 的 
任务 进行 回 演 。 怎 么 回 深 ? 根据 事务 日 志 进 行 回 滚 ! 新 增加 的 一 个 命 
令 CancelDeletePageCommand 实 现 撤销 刚刚 发 出 的 删除 命令 ， 如 代码 清 
单 15-21 所 示 。 


代码 清单 15-21 撤销 命令 


public class CancelDeletePageCommand extends Command { 
// 撤 销 删 除 一 个 页 面 的 命令 
public void execute() { 


Super ,pg,rollBack( ); 


然后 就 是 用 Invoker 进 行 调用 了 ， 客 户 选 择 了 执行 这 个 撤销 动作 ， 
束 可 以 进行 撤销 操作 ， 该 示意 代码 确实 比较 简单 ， 真 正 实 现 起 来 那 是 
异常 复杂 的 ， 为 什么 呢 ? 事务 日 志 处 理 是 非常 繁琐 的 处 理 机 制 ， 想 想 
数据 库 的 日 志 处 理 吧 ， 你 束 能 想象 出 这 个 日 志 有 多 复 洒 | 


15.5 最 佳 实践 


各 位 读者 可 能 已 经 发 觉 了 这 样 的 问题 ， 在 我 们 旅行 社 的 例子 中 ， 
我 们 的 Receiver 角 色 (也 就 是 Group 的 三 个 实现 类 ) 并 没有 暴露 给 
Client， 而 在 通用 的 类 图 和 源码 中 却 出 现 了 Client 类 对 Receiver 角 色 的 依 
赖 ， 这 是 为 什么 呢 ? 


如 果 你 发 现 了 这 个 问题 ， 则 说 明 你 阅读 得 非常 仔细 ， 好 习惯 
一 个 模式 到 实际 应 用 的 时 候 都 有 一 些 变形 ， 命 令 模式 的 Receiver 在 实 
际 应 用 中 一 般 都 会 被 封装 掉 (除非 非常 必要 ， 例 如 撤销 处 理 ) ， 那 是 
因为 在 项 目 中 : 约定 的 优先 级 最 高 ， 每 一 个 命令 是 对 一 个 或 多 个 
Receiver 的 封装 ， 我 们 可 以 在 项 目 中 通过 有 意义 的 类 名 或 命令 名 处 理 
命令 角色 和 接收 者 角色 的 耦合 关系 (这 就 是 约定 ) ， 减 少 高 层 模 块 
(Client 类 ) 对 低层 模块 (Receiver 角 色 类 ) 的 依赖 关系 ， 提 高 系统 整 
体 的 稳定 性 。 因 此 ， 建 议 大 家 在 实际 的 项 目 开 发 时 采用 封闭 Receiver 
的 方式 〈 当 人 然 了 ， 仁 者 见 仁 ， 智 者 见 智 ) ， 减 少 Client 对 Reciver 的 依 
赖 ， 该 方案 只 是 对 Commandd 抽 象 类 及 其 子 类 有 一 定 的 修改 ， 
Command 类 如 代码 清单 15-22 所 示 。 


代码 清单 15-22 完美 的 Command 类 


public abstract class Command { 
// 定 义 一 个 子 类 的 全 局 共享 变量 


protected final Receiver recelver 

// 实 现 类 必须 定义 一 个 接收 者 

public Command(Receiver _receliver){ 
this.receiver = _receiver,; 


} 
// 每 个 命令 类 都 必须 有 一 个 执行 命令 的 方法 
public abstract void execute() ; 


在 Command 父 类 中 声明 了 一 个 接收 者 ， 通 过 构造 画 数 约定 每 个 具 
体 命 令 都 必须 指定 接收 者 ， 当 然 根 据 开 发 场景 要 求 也 可 以 有 多 个 接收 
者 ， 那 殴 需 要 用 集合 类 型 。 我 们 来 看 具体 命令 ， 如 代码 清单 15-23 所 


尔 。 


代码 清单 15-23 具体 的 命令 


public class ConcreteCommand1 extends Command { 
// 声 明 目 己 的 默认 接收 者 

public Concretecommand1( ){ 
super(new ConcreteReciver1()); 


} 

// 设 置 新 的 接收 者 

public ConcreteCommandi(Receiver _receiver)t{ 
super(_receiver); 


} 
// 每 个 具体 的 命令 都 必须 实现 一 个 命令 
public void execute() { 
// 业 务 处 理 
super.receiver.doSomething(); 


} 


public class ConcreteCommand2 extends Command { 
// 声 明 目 己 的 默认 接收 者 

public ConcreteCommand2(){ 
super(new ConcreteReciver2() ) ; 


} 

// 设 置 新 的 接收 者 

public ConcreteCommand2(Receiver _receiver)t{ 
super(_receiver); 


} 
// 每 个 具体 的 命令 都 必须 实现 一 个 命令 


public void execute() { 
// 业 务 处 理 
super.receiver.doSomething(); 


这 确实 简化 了 很 多 ， 每 个 命令 完成 单一 的 职责 ， 而 不 是 根据 接收 
者 的 不 同 完成 不 同 的 职员 。 在 高 层 模块 的 调用 时 整 不 用 考虑 接收 者 是 
谁 的 问题 ， 如 代码 清单 15-24 所 示 。 


代码 清单 15-24 场景 类 


public class Client { 

public static void main(String[|] args) { 
// 首 先 声明 调用 者 Invoker 
Invoker invoker = new Invoker(); 
// 定 义 一 个 发 送 给 接收 者 的 命令 
Command command = new Concretecommand1( ) ; 
// 把 命令 交 给 调用 者 去 执行 
invoker.setCommand(command); 
invoker .action( ) ; 


高 层次 的 模块 不 需要 知道 接收 者 ，Perfect! 读 者 可 以 在 实际 应 用 中 
采用 该 模式 ， 看 看 威力 如 何 。 


第 16 章 ”责任 链 模式 


16.1 古代 妇女 的 材 锁 一 一 “三 从 四 德 ” 


中 国 记 代 对 妇女 制定 了 “三 从 四 德 " 的 道德 规范 , “三 从 ”是 指 “ 未 尹 
从 父 、 既 巡 从 夫 、 夫 死 从 子 ”。 也 就 是 说 ， 一 位 女性 在 结婚 之 前 要 听从 
于 父 杀 ， 绪 婚 之 后 要 听从 于 丈夫 ， 如 采 丈 夫 死 了 还 要 听从 于 儿子 。 举 
例 来 说 ， 如 果 一 位 女性 要 出 去 逛街 ， 在 她 出 媒 前 必须 征 得 父亲 的 同 

， 出 嫁 之 后 必须 获得 丈夫 的 许可 ， 那 丈夫 死 了 怎么 办 ? 那 束 得 问 问 
儿子 是 否 允 许 目 己 出 去 逛街 。 佑 计 你 搂 下 来 马上 要 问 :“ 要 是 没有 儿 于 
皇 么 办 ? " 那 束 请 示 小 板子 、 侄 子 等 。 在 父系 社会 中 ， 妇 文 只 占 从 属地 
位 ， 现 在 想 想 中 国 百 代 的 妇 文 还 是 挺 悲 惨 的 ， 连 逛街 都 要 多 得 请 示 。 
作为 父 茶 、 丈 夫 或 儿 了 于， 只 有 两 种 选择 ， 要 不 承担 起 责任 来 ， 允 许 她 
或 不 允许 她 竹 街 ， 要 不 就 让 她 请 示 下 一 个 人 ， 这 古 整 个 社会 体系 的 约 
束 ， 应 用 到 我 们 项 目 中 就 是 业务 规则 。 下 面 来 看 如 何 通过 程序 来 实 
现 “ 三 从 ”， 和 需求 很 简单 :通过 程序 描述 一 下 古代 妇女 的 “三 从 ”制度 。 
好 ， 我 们 先 来 看 类 图 ， 如 图 16-1 所 示 。 


IWomen <<interface>> 
| IHandler 


-控制 权 的 抽象 


TU pi 5 
+String getRequest() +void Handle Message(IWomen women) 


| | | 
上 <= | EE 


图 16-1 妇女 “三 从 ”类 图 


类 图 非常 简单 ，IHandler 是 三 个 有 诀 策 权 对 象 的 接口 ，IWomen 是 
女性 的 代码 ， 其 实现 也 非常 简单 ，IWomen 如 代码 清单 16-1 所 示 。 


代码 清单 16-1 女性 接口 


public interface IWomen { 
// 获 得 个 人 状况 
public int getType(); 
// 获 得 个 人 请 示 ， 你 要 干什么 ? 出 去 逛街 ? 约会 ?还 是 看 电影 ? 
public String getRequest(); 


女性 接口 仅 两 个 方法 ， 一 个 是 取得 当前 的 个 人 状况 getType， 通 过 
返回 值 决 定 是 结婚 了 还 是 没 结 婚 、 丈 夫 是 否 在 世 等 ， 男 外 一 个 方法 
getRequest 是 要 请 示 的 内 容 ， 要 出 去 选 街 还 是 吃饭 ， 其 实现 类 如 代码 清 
单 16-2 所 示 。 


代码 清单 16-2 古代 妇女 


public class Women implements IWoment{ 
7 
* 通过 一 个 int 类 型 的 参数 来 描述 妇女 的 个 人 状况 
* 1-- 未 出 嫁 


* 2-- 出 嫁 
* 3-- 夫 和 死 
*/ 
private int type=0; 
// 妇 女 的 请 示 
private String request = ""; 
// 构 造 函 数 传递 过 来 请 求 
public Women(int _type,String _request)t{ 
this.type = _type; 
this.request = _request; 


} 

// 获 得 自己 的 状况 

public int getType(){ 
return this.type; 


} 

// 获 得 妇女 的 请 求 

public String getRequest()t 
return this.request,; 

} 


我 们 使 用 数字 来 代表 女性 的 不 同 状 态 ， 1 是 未 结婚 ，2 是 已 经 结婚 
的 ， 而 且 丈 夫 健 在 ;3 是 丈夫 去 世 了 “。 从 整个 设计 上 分 析 ， 有 处 理 权 的 
人 如 父亲 、 丈 夫 、 儿 子 ) 才 是 设计 的 核心 ， 他 们 是 要 处 理 这 些 请 求 
的 ， 我 们 来 看 有 处 理 权 的 人 员 接口 THandler， 如 代码 清单 16-3 所 示 。 


代码 清单 16-3 有 处 理 权 的 人 员 接 口 


public interface IHandler { 
// 一 个 女性 (女儿 、 妻 子 或 者 母亲 ) 要 求 竹 街 ， 你 要 处 理 这 个 请 求 


public void HandleMessage(IWomen women ); 


非常 简单 ， 有 处 理 权 的 人 对 妇女 的 请 求 进行 处 理 ， 分 别 有 三 个 实 
现 类 ， 在 女儿 没有 出 嫁 之 前 父亲 是 有 决定 权 的 ， 其 实现 类 如 代码 清单 
16-4 所 示 。 


代码 清单 16-4 父亲 类 


public class Father implements IHandler { 
// 未 出 嫁 的 女儿 来 请 示 父 杀 
public void HandleMessage(IWomen women) { 
System,.out ,println(" 女 儿 的 请 示 
是 : "+women ,getRequest()); 
System.out.println(" 父 亲 的 答复 是 :同意 ")， 
} 


在 女性 出 媒 后 ， 丈 夫 有 决定 权 ， 如 代码 清单 16-5 所 示 。 


代码 清单 16-5 丈夫 类 


public class Husband implements IHandler { 
// 妻 子 向 丈夫 请 示 
public void HandleMessage(IWomen women) { 
System.out.println(" 妻 子 的 请 示 
是 : "+women ,getRequest()); 
System.out.println(" 丈 夫 的 答复 是 ， 同意 ")， 
} 


在 女性 起 便 后 ， 对 母 杀 提出 的 请 求 儿 子 有 决定 权 ， 如 代码 清单 16-6 
扩 示 


代码 清单 16-6 儿子 类 


public class Son implements IHandler { 
// 母 亲 向 儿子 请 示 
public void HandleMessage(IWomen women) { 
System.out .println(" 母 亲 的 请 示 
是 : "+women ,getRequest()); 
System.out.println(" 儿 子 的 答复 是 ， 同意 " ) ; 
} 


以 上 三 个 实现 类 非常 简单 ， 只 有 一 个 方法 ， 处 理 文 儿 、 妻 子 、 
亲 提 出 的 请 求 ， 我 们 来 模拟 一 下 一 个 古代 妇女 出 去 得 街 是 如 何 请 示 
的 ， 如 代码 清单 16-7 所 示 。 


代码 请 单 16-7 场景 


public class Client { 
public static void main(String[] args) { 
// 随 机 挑选 几 个 女性 
Random rand = new Random( ) ; 
ArrayList<IWomen> arrayList = new ArrayList(); 
for(int i=0;1i<5;i++){ 
arrayList.add(new Women(rand.nextInt(4)," 我 


要 出 去 逛街 " ) ) ; 
// 定 义 三 个 请 示 对 象 
IHandler father = new Father(); 
IHandler husband = new Husband(); 
IHandler son = new Son(); 
for(IWomen women:arrayList)t 
if(women.getType() ==1){ // 未 结婚 少女 ， 请 示 父 


System.out.printin("\n-------- 女儿 同 
人 py 
father .HandleMessage(women); 
}else if(women.getType() ==2){ // 已 婚 少 妇 ， 
请 示 丈 夫 
System.out.println("Nxn-------- 妻子 向 
丈夫 请 示 =------ 
husband.HandleMessage (women ) ; 
}else if(women.getType() == 3){ // 母 亲 请 示 儿 
子 
System.out.println("Nxn-------- 母亲 问 
0 
son.HandleMessage(women ); 
}else 
// 暂 时 什么 也 不 做 
} 
} 


首先 是 通过 随机 方法 产生 了 5 个 古代 妇女 的 对 象 ， 然 后 看 她 们 是 如 
何 台 逛街 这 件 事 去 请 示 的 ， 运 行 结 果 如 下 所 示 〈 由 于 是 随机 的 ， 您 看 


到 的 结果 可 能 和 这 里 有 所 不 同 ) : 


-------- 女儿 向 父亲 请 示 ------- 
女儿 的 请 示 是 : 我 要 出 去 逛街 
父亲 的 答复 是 : 同意 

---- 母 亲 向 儿子 请 示 ------- 
母亲 的 请 示 是 : 我 要 出 去 逛街 
儿子 的 答复 是 : 同意 
~ 妻子 向 丈夫 请 示 ------- 
妻子 的 请 示 是 : 我 要 出 去 逛街 
丈夫 的 答复 是 : 同意 
-------- 女儿 向 父亲 请 示 ------- 
女儿 的 请 示 是 : 我 要 出 去 逛街 
父亲 的 答复 是 : 同意 


“三 从 四 德 ”的 旧 社 会 规范 已 经 完整 地 表现 出 来 了 ， 你 看 谁 向 谁 请 
示 都 定义 出 来 了 ， 但 是 你 是 不 是 发 现 这 个 程序 写 得 有 点 不 舒服 ?” 有 点 
别扭 ? 有 点 想 重 构 它 的 感觉 ? 那 束 对 了 ! 这 段 代 码 有 以 下 几 个 问题 ; 


占 相 


WA 


。 职 贡 界定 不 清晰 


对 女儿 提出 的 请 示 ， 应 该 在 父 杀 类 中 做 出 决定 ， 父 杀 有 责任 、 有 
义务 处 理 女儿 的 请 示 ， 因 此 Father 类 应 该 是 知道 女儿 的 请 求 目 己 处 理 ， 
而 不 是 在 Client 类 中 进行 组 狼 出 来 ， 也 束 是 说 原本 应 该 古 父 亲 这 个 类 做 
的 事情 抛 给 了 其 他 类 进行 处 理 ， 不 应 该 是 这 样 的 。 


e 代码 胱 肿 


我 们 在 Client 类 中 写 了 if...else 的 判断 条 件 ， 而 且 能 随 着 能 处 理 该 类 
型 的 请 示人 员 越 多 ， 让 ..else 的 判断 融 越 多 ， 想 想 看 ， 胁 肿 的 条 件 判 晰 


还 怎么 有 可 读 性 ? ! 
e 耦合 过 重 


这 是 什么 意思 呢 ， 我 们 要 根据 Women 的 type 来 决定 使 用 IHandler 的 
那个 实现 类 来 处 理 请 求 。 有 一 个 问题 是 : 如果 IHandler 的 实现 类 继续 扩 
展 怎么 办 ? 修改 Client 类 ? 与 开 闭 原则 违背 了 |! 


e 异 闻 情况 灾 考 虑 


妻子 只 能 癌 丈 夫 请 示 吗 ? 如 果 妻 子 (比如 一 个 现代 女性 罕 越 到 古 
代 了 ,不 懂 什 么 “三 从 四 德 ”) 向 自己 的 父亲 请 示 了 ， 父 亲 应 该 做 何 处 
理 ? 我 们 的 程序 上 可 没有 体现 出 来 ， 逻 辑 失 败 了 | 


既然 有 这 么 多 的 问题 ， 那 我 们 要 想 办 法 来 解决 这 些 问题 ， 我 们 先 
来 分 析 一 下 需求 ， 女 性 提出 一 个 请 示 ， 必 然 要 获得 一 个 答复 ， 硬 管 是 


同意 还 是 不 同意 ， 总 之 是 要 一 个 答复 的 ， 而 且 这 个 答复 是 唯一 的 ， 不 
能 说 旦 父亲 作出 一 个 决断 ， 而 丈夫 也 作出 了 一 个 决断 ， 也 即 是 请 示 传 
递 出 去 ， 必 然 有 一 个 唯一 的 处 理 人 给 出 唯一 的 答复 ，OK， 分 析 完 毕 ， 
收工 ， 重 新 设计 ， 我 们 可 以 抽象 成 这 样 一 个 结构 ， 女 性 的 请 求 先 发 送 
到 父 杀 类 ， 父 亲 类 一 看 是 目 己 要 处 理 的 ， 殊 作出 回应 处 理 ， 如 采 女 儿 
已 经 出 巡 了 ， 那 惑 有 要 把 这 个 请 求 转 发 到 女婿 来 处 理 ， 那 女婿 一 旦 去 天 
国 报道 了 ， 那 就 由 儿子 来 处 理 这 个 请 求 ， 类 似 于 如 图 16-2 所 示 的 顺序 处 
理 图 。 


t 
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a 
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丈夫 做 出 回应 
儿子 做 出 回应 
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图 16-2 女性 请 示 的 顺序 处 理 图 


父亲 、 丈 夫 、 儿 子 每 个 和 点 有 两 个 选择 要么 承担 责任 ， 做 出 回 
应 ; 要么 把 请 求 转发 到 后 序 环节 。 结 构 分 析 得 已 经 很 清楚 了 ， 那 我 们 
看 起 么 来 实现 这 个 功能 ， 类 图 重新 修正 ， 如 图 16-3 所 示 。 


hanlderMessage(): 处 理 请 求 
setNext0: 设置 下 一 个 处 理 环 节 是 谁 


古代 女性 的 代表 response(): 回应 ， 各 个 实现 类 实现 


Handler 


IWomen 
= = == 一 


+int getType() 


+final vold Handle Message(IWomen women) 
+void setNext(Handler handler) 
#yoid response(IWomen women) 


+String getRequest() 


Wome | | 
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图 16-3 顺序 处 理 的 类 图 


从 类 图 上 看 ， 三 个 实现 类 Father、Husband、Son 只 要 实现 构造 画 数 
和 父 类 中 的 抽象 方法 response 就 可 以 了 ， 具 体 由 谁 处 理 女性 提出 的 请 
求 ， 都 已 经 转移 到 了 Handler 抽 象 类 中 ， 我 们 来 看 Handler 怎 么 实现 ， 如 
代码 清单 16-8 所 示 。 


代码 清单 16-8 修改 后 的 Handler 类 


public abstract class Handler { 
public final static int FATHER_LEVEL REQUEST = 
public final static int HUSBAND_LEVEL REQUEST 
public final static int SON_LEVEL REQUEST = 3; 
// 能 处 理 的 级 别 
private int level =0; 
// 责 任 传递 ， 下 一 个 人 责任 人 是 谁 
private Handler nextHandler; 
// 每 个 类 都 要 说 明 一 下 自己 能 处 理 哪些 请 求 
public Handler(int _level)t{ 
this.level = _level; 
} 


1; 
= 人 2 


// 一 个 女性 (女儿 、 妻 子 或 者 是 母亲 ) 要 求 逛 衙 ， 你 要 处 理 这 个 请 求 
public final void HandleMessage(IWomen women){ 
if(women.getType() == this.level)t{ 
this.response(women); 
}elsef 
if(this.nextHandler != null){ // 有 后 续 环节 
才 把 请 求 往 后 递送 


this,nextHandler.HandleMessage(women ) ， 
}else{f // 已 经 没有 后 续 处 理 人 了 ， 不 用 处 理 了 
System.out.println("--- 没 地 方 请 示 了 ， 按 不 


同意 处 理 - - -\n"); 


} 
* 如 果 不 属于 你 处 理 的 请 求 ， 你 应 该 让 她 找 下 一 个 环节 的 人 ， 如 女儿 出 嫁 了 
* 还 回 父 杀 请 示 是 否 可 以 逛街 ， 那 父亲 就 应 该 告诉 女儿 ， 应 该 找 丈 夫 请 示 


*/ 
public void setNext(Handler _handler){ 
this.nextHandler = _handler; 
} 
// 有 请 示 那 当然 要 回应 


protected abstract void response(IWomen women ) ; 


方法 比较 长 ， 但 是 还 是 比较 简单 的 ， 读 者 有 没有 看 到 ， 其 实在 这 
里 也 用 到 模板 方法 模式 ， 在 模板 方法 中 判断 请 求 的 级 别 和 当前 能 够 处 
理 的 级 别 ， 如 果 相 同 则 调用 基本 方法 ， 做 出 有 反馈， 如 末 不 相等 ， 则 传 
累 到 下 一 个 环节 ， 由 下 一 环 市 做 出 回应 ， 如 琳 已 经 达到 环 市 结尾 ， 则 
直接 做 不 同意 处 理 。 基 本 方法 response 需 要 各 个 实现 类 实现 ， 每 个 实现 
类 只 要 实现 两 个 职责 : 一 是 定义 目 己 能 够 处 理 的 等 级 级 别 ， 二 是 对 请 
求 做 出 回应 ， 我 们 首先 来 看 首 节 点 Father 类 ， 如 代码 清单 16-9 所 示 。 


代码 清单 16-9 父亲 类 


public class Father extends Handler { 
// 父 亲 只 处 理 女 儿 的 请 求 


public Father(){ 
super (Handler .FATHER_ LEVEL REQUEST); 


} 

// 父 亲 的 答复 

protected void response(IWomen women) { 
System.out.printin("-------- 女儿 向 父亲 请 示 ------- "); 


System.out.println(women.getRequest()); 
System.out.println(" 父 亲 的 答复 是 :同意 \n" ) ， 


丈夫 类 定义 目 己 能 处 理 的 等 级 为 2 的 请 示 ， 如 代码 清单 16-10 所 示 。 


代码 清单 16-10 丈夫 类 


public class Husband extends Handler { 
// 丈 夫 只 人 处理 妻子 的 请 求 
public Husband( ){ 
super (Handler .HUSBAND_LEVEL_REQUEST); 


} 

// 丈 夫 请 示 的 答复 

protected void response(IWomen women) { 
System.out.println("-------- 妻子 向 丈夫 请 示 ------- 


System.out.println(women.getRequest()); 
System.out.println(" 丈 夫 的 答复 是 : 同意 \n" ) ， 


儿子 类 只 能 处 理 等 级 为 3 的 请 示 ， 如 代码 请 单 16-11 所 示 。 


代码 清单 16-11 儿子 类 


public class Son extends Handler { 
// 儿 子 只 处 理 母 亲 的 请 求 
public Son( ){ 
Super(Handler.SON_LEVEL_REQUEST ) ; 


} 

// 儿 子 的 答复 

protected void response(IWomen women) { 
System.out.println("-------- 母亲 向 儿子 请 示 ------- Ly 


System.out.println(women.getRequest()); 
System.out.println(" 儿 子 的 答复 是 : 同意 \n")，; 


这 三 个 类 都 很 简单 ， 构 造 方法 是 必须 实现 的 ， 父 类 框 定 子 类 必须 
有 一 个 显 式 构造 隙 数 ， 了 于 类 不 实现 编译 不 通过 。 通 过 构造 方法 我 们 设 
置 了 各 个 类 能 处 理 的 请 求 类 型 ，Father 只 能 处 理 请 求 类 型 为 1 (也 就 是 
女儿 ) 的 请 求 ，Husband 只 能 处 理 请 求 类 型 类 为 2 (也 就 是 妻子 ) 的 请 
求 ， 儿 子 只 能 处 理 请 求 类 型 为 3 (也 就 是 母亲 ) 的 请 求 ， 那 如 果 请 求 类 
型 为 4 的 该 如 何 处 理 呢 ?在 Handler 中 我 们 已 经 判断 了 ， 如 何 没有 相应 的 
处 理 者 (也 就 是 没有 下 一 环节 ) ， 则 视 为 不 同意 。 


Women 类 的 接口 没有 任何 变化 ， 请 参考 图 16-1 所 示 。 


实现 类 稍微 有 些 变 化 ， 如 代码 清单 16-12 所 示 。 


代码 清单 16-12 女性 类 


public class Women implements IWoment{ 
/* 
* 通过 一 个 Int 类 型 的 参数 来 描述 妇女 的 个 人 状况 
* 1-- 未 出嫁 


private int type=0; 

// 妇 女 的 请 示 

private String request = ""; 

// 构 造 函 数 传递 过 来 请 求 

public Women(int ap 0 _request)t{ 
this.type = 
// 为 了 便于 显示 ， - 容 六 生 做 了 点 处 理 
switch(this. type)t{ 
case 1: 


this.request = "女儿 的 请 求 是 : " + 
_redquest 


break; 


case 2: 
this.request = "妻子 的 请 求 是 : " + 
_request,; 
break; 
case 3: 
this.request = "母亲 的 请 求 是 : " + 
_request,; 
} 


} 

// 获 得 自己 的 状况 

public int getType(){ 
return this.type; 


} 

// 获 得 妇女 的 请 求 

public String getRequest()t 
return this.request,; 

} 


为 了 展示 结果 清晰 一 点 ，Women 类 做 了 一 些 改变 。 我 们 再 来 看 
Client 类 是 怎么 描述 古代 这 一 个 礼节 的 ， 如 代码 清单 16-13 所 示 。 


代码 清单 16-13 场景 


public class Client { 
public static void main(String[] args) { 
// 随 机 挑选 几 个 女性 
Random rand = new Random( ) ; 
ArrayList<IWomen> arrayList = new ArrayList(); 
for(int i=0;i<5;i++){ 
arrayList.add(new Women(rand.nextInt(4), "我 要 


过 


出 去 逛街 ") ) ; 


党 
rn 


// 定 义 三 个 请 示 对 象 
Handler father = new Father(); 
Handler husband = new Husband( ) ， 
Handler son = new Son(); 
// 设 置 请 示 顺 序 
father.setNext(husband); 
husband.setNext (son); 
for(IWomen women:arrayList)t 

father .HandleMessage (women ) ; 
} 


在 Client 中 设置 请 求 的 传递 顺序 ， 先 加 父亲 请 示 ， 不 是 父亲 应 该 解 
决 的 问题 ， 则 由 父 杀 传 递 到 丈夫 类 解决 ， 奉 不 是 丈夫 类 解决 的 问题 则 
传递 到 儿子 类 解决 ， 最 终 的 结果 必然 有 一 个 返回 ， 其 运行 结 末 如 下 所 


修 ° 


妻子 的 请 求 是 : 我 要 出 去 逛街 


丈夫 的 答复 是 : 同意 


母亲 的 请 求 是 : 我 要 出 去 逛街 


儿子 的 答复 是 : 同意 


丈夫 的 答复 是 : 同意 


结果 也 正确 ， 业 务 调 用 类 Client 也 不 用 去 做 判断 到 底 是 需要 谁 去 处 
理 ， 而 且 Handler 抽 和 象 类 的 子 类 可 以 继续 增加 下 去 ， 只 需要 扩展 传递 链 
而 已 ， 调 用 类 可 以 不 用 了 解 变 化 过 程 ， 甚 至 是 谁 在 处 理 这 个 请 求 都 不 
用 知道 。 在 这 种 模式 下 ， 即 使 现代 社会 的 一 个 小 太 妹 穿越 到 古代 〈 例 
如 掉 入 时 空 障 道 ， 或 者 时 空 突然 扭转 ， 甚 至 是 突然 魔法 显灵 ) ， 对 “三 
从 四 德 ”没有 任何 了 解 也 可 以 自由 地 应 付 ， 反 正 只 要 请 示 父 杀 就 可 以 
了 ， 该 父 杀 处 理 束 父 杀 处 理 ， 不 该 父亲 处 理 就 往 下 传递 。 这 束 是 责任 
链 模 式 。 


16.2 责任 链 模式 的 定义 


责任 链 模式 定义 如 下 : 


Avoid coupling the sender of a request to its receiver by giving more 
than one object a chance to handle the request.Chain the receiving objects 
and pass the request along the chain until an object handles it. (使 多 个 对 
象 都 有 机 会 处 理 请 求 ， 从 而 避免 了 请 求 的 发 送 者 和 接受 者 之 间 的 耦合 
关系 。 将 这 些 对 象 连 成 一 条 链 ， 并 沿 着 这 条 链 传 递 该 请 求 ， 直 到 有 对 
象 处 理 它 为 止 。) 


责任 链 模式 的 重点 是 在 “ 链 ” 上 ， 由 一 条 链 去 处 理 相似 的 请 求 在 链 
中 决定 谁 来 处 理 这 个 请 求 ， 并 返回 相应 的 结 宁 ， 其 通用 类 图 如 图 16-4 
Wa 
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图 16-4 责任 链 模式 通用 类 图 


责任 链 模 式 的 核心 在 “ 链 ” 上 ,“ 链 ?是 由 多 个 处 理 者 
ConcreteHandler 组 成 的 ， 我 们 先 来 看 抽象 Handler 类 ， 如 代码 清单 16-14 
所 示 。 


代码 清单 16-14 抽象 处 理 者 


public abstract class Handler { 
private Handler nextHandler; 
// 每 个 处 理 者 都 必须 对 请 求 做 出 处 理 
public final Response handleMessage(Request request)t{ 
Response response = null; 
// 判 断 是 否 是 自己 的 处 理 级 别 


if(this.getHandlerLevel().equals(request.getRequestLevel()))t{ 
response = this.echo(request); 
}else{ // 不 属于 自己 的 处 理 级 别 
// 判 断 是 否 有 下 一 个 处 理 # 
if(this.nextHandler != null)t{ 
response = 
this.nextHandler.handleMessage(request); 


}elsef{ 
// 没 有 适当 的 处 理 者 ， 业 务 自 行 处 理 
} 


return response,; 


} 

// 设 置 下 一 个 处 理 者 是 谁 

public void setNext(Handler _handler){ 
this.nextHandler = _handler; 


} 

// 每 个 处 理 者 都 有 一 个 处 理 级 别 

protected abstract Level getHandlerLevel(); 

// 每 个 处 理 者 都 必须 实现 处 理 任务 

protected abstract Response echo(Request request); 


抽象 的 处 理 者 实现 三 个 职责 : 一 是 定义 一 个 请 求 的 处 理 方法 
handleMessage， 唯 一 对 外 开放 的 方法 ;二 是 定义 一 个 链 的 编排 方法 
setNext， 设 置 下 一 个 处 理 者 ; 三 是 定义 了 具体 的 请 求 者 必须 实现 的 两 
个 方法 : 定义 上 自己 能 够 处 理 的 级 别 getHandlerLevel 和 具体 的 处 理 任务 


echo° 


注意 ”在 责任 链 模式 中 一 个 请 求 发 送 到 链 中 后 ， 前 一 市 点 消费 部 
分 消 轧 ， 然 后 交 由 后 续 市 点 继 续 处 理 ， 最 终 可 以 有 处 理 结果 也 可 以 没 
有 处 理 结果 ， 读 者 可 以 不 用 理会 什么 纯 的 、 不 纯 的 贡 任 链 模 式 。 同 
时 ， 请 读者 注意 handlerMessage 方 法 前 的 final 关 键 字 ， 可 以 阅读 第 10 章 
的 模板 方法 模式 。 


我 们 定义 三 个 具体 的 处 理 者 ， 以 便 可 以 组 成 一 个 链 ， 如 代码 清单 


16-15 所 示 。 


代码 清单 16-15 具体 处 理 者 


public class ConcreteHandler1 extends Handler { 
// 定 义 自己 的 处 理 逻 辑 
protected Response echo(Request request) { 
// 完 成 处 理 逻 辑 
return null; 


} 

// 设 置 自己 的 处 理 级别 

protected Level getHandlerLevel() { 
// 设 置 自己 的 处 理 级 别 


return null; 


} 


public class ConcreteHandler2 extends Handler { 
// 定 义 自己 的 处 理 罗 辑 
protected Response echo(Request request) { 
// 完 成 处 理 逻 辑 
return null; 


} 

// 设 置 自己 的 处 理 级别 

protected Level getHandlerLevel() { 
// 设 置 自己 的 处 理 级 别 


return null; 


} 


public class ConcreteHandler3 extends Handler { 
// 定 义 自己 的 处 理 罗 辑 
protected Response echo(Request request) { 
// 完 成 处 理 逻 辑 
return null; 


} 

// 设 置 自己 的 处 理 级 别 

protected Level getHandlerLevel() { 
// 设 置 自己 的 处 理 级别 


return null; 


在 处 理 者 中 涉及 三 个 类 : Level 类 负责 定义 请 求 和 人 处理 级 别 ， 


Request 类 人 负责 封 狂 请 求 ，Response 人 负责 封装 链 中 返回 的 结果 ， 该 三 个 


类 都 需要 根据 业务 产生 ， 读 者 可 以 在 实际 应 用 中 完成 相关 的 业务 填 
充 ， 其 框架 代码 如 代码 清单 16-16 所 示 。 
代码 清单 16-16 模式 中 有 关 框 架 代 码 


public class Level { 
// 定 义 一 个 请 求 和 处 理 等 级 


public class Request { 
// 请 求 的 等 级 
public Level getRequestLevel(){ 
return null; 
上 


public class Response { 


// 处 理 者 返回 的 数据 


在 场景 类 或 高 层 模 块 中 对 链 进 ， 并 传递 请 求 ， 返 回 结果 ， 
如 代码 清单 16-17 所 示 。 


代码 清单 16-17 场景 类 


public class Client { 
public static void main(String[|] args) { 

// 声 明 所 有 的 处 理 节 点 

Handler handler1 = new ConcreteHandler1(); 
Handler handler2 = new ConcreteHandler2(); 
Handler handler3 = new ConcreteHandler3(); 
// 设 置 链 中 的 阶段 顺序 1- ->2- ->3 
handleri1.setNext(handler2); 
handler2.setNext(handler3); 

// 提 交 请 求 ， 返 回 结果 
Response response = handleri.handlerMessage(new 


Request( ) ) ， 
} 


. 


在 实际 应 用 中 ， 一 般 会 有 一 个 封闭 类 对 责任 模式 进行 封闭， 也 束 
征 替 代 Client 类 ， 直 接 返 回 链 中 的 第 一 个 处 理 者 ， 具 体 链 的 设置 不 需要 
高 层次 模块 和 关系， 这样， 更 简化 了 高 层次 模块 的 调用 ， 减 少 模块 间 的 
硝 合 ， 提 高 系统 的 灵活 性 。 


16.3 贡 任 链 模 式 的 应 用 
16.3.1 责任 链 模式 的 优点 

责任 链 模 式 非常 显著 的 优点 是 将 请 求 和 处 理 分 开 。 请 求 者 可 以 不 
用 知道 是 谁 处 理 的 ， 处 理 者 可 以 不 用 知道 请 求 的 全 摇 (例如 在 J2EE 项 


目 开发 中 ， 可 以 剥离 出 无 状态 Bean 由 责任 链 处 理 ) ， 两 者 解 而 ， 提 高 
系统 的 灵活 性 。 


16.3.2 责任 链 模式 的 缺点 


责任 链 有 两 个 非常 显著 的 缺点 : 一 是 性 能 问题 ， 每 个 请 求 都 症 从 
链 头 志 历 到 链 尾 ， 竺 别 是 在 链 比较 长 的 时 候 ， 性 能 是 一 个 非常 大 的 问 
题 。 二 征调 试 不 很 方便 ， 竺 别 是 链条 比较 长 ， 环 下 比 较 多 的 时 候 ， 由 
于 采用 了 类 似 递 归 的 方式 ， 调 试 的 时 候 逻 辑 可 能 比较 复杂 。 


16.3.3 责任 链 模式 的 注意 事项 
链 中 节点 数量 需要 控制 ， 避 免 出 现 超 长 链 的 情况 ， 一 般 的 做 法 是 


在 Handler 中 设置 一 个 最 大 市 点 数量 ， 在 setNext 方 法 中 判断 是 否 已 经 古 


超过 其 闵 值 ， 超 过 则 不 允许 该 链 建 立 ， 避 人 免 无 意识 地 破坏 系统 性 能 。 


16.4 最 住 实践 


在 例 了 于 和 通用 源码 中 Handler 古 抽象 类 ， 融 合 了 模板 方法 模式 ， 每 
个 实现 类 只 要 实现 两 个 方法 : echo 方 法 处 理 请 求 和 getHandlerLevel 获 得 
处 理 级 别 ， 想 想 单一 职责 原则 和 巡 米 特 法 则 吧 ， 通 过 融合 模板 方法 模 
式 ， 各 个 实现 类 只 要 关注 的 自己 业务 逻辑 就 成 了 ， 至 于 说 什么 事 要 目 
己 处 理 ， 那 天 让 父 类 去 决定 好 了 ， 也 融 是 说 父 类 实现 了 请 求 传递 的 功 
能 ， 了 于 类 实现 请 求 的 处 理 ， 符 合 单一 职 贡 原则 ， 各 个 实现 类 只 完成 一 
个 动作 或 逻辑 ， 也 就 是 只 有 一 个 原因 引起 类 的 改变 ， 我 建议 大 家 在 使 
用 的 时 候 用 这 种 方法 ， 好 处 是 非常 明显 的 了 ， 了 于 类 的 实现 非常 简单 ， 
责任 链 的 建立 也 是 非常 灵活 的 。 


责任 链 模 式 屏 菩 了 请 求 的 处 理 过 程 ， 你 发 起 一 个 请 求 到 展 是 谁 处 
理 的 ， 这 个 你 不 用 关心 ， 只 要 你 把 请 求 抛 给 责任 链 的 第 一 个 处 理 者 ， 
最 终 会 返回 一 个 处 理 结果 〈 当 然 也 可 以 不 做 任何 处 理 ) ， 作 为 请 求 者 
可 以 不 用 知道 到 的 是 需要 谁 来 处 理 的 ， 这 是 责任 链 模 式 的 核心 ， 同 时 
责任 链 模式 也 可 以 作为 一 种 补救 模式 来 使 用 。 举 个 人 简单 例子 ， 如 项 目 
开发 的 时 候 ， 和 需求 确认 是 这 样 的 ， 一 个 请 求 (如 银行 客户 存款 的 币 
种 ) ， 一 个 处 理 者 (只 处 理 人 民 币 ) ， 但 是 随 着 业务 的 发 展 (改革 开 
放 了 嘛 ， 还 要 处 理 美 元 、 日 元 等 ) ， 处 理 者 的 数量 和 类 型 都 有 所 增 
加 ， 那 这 时 候 就 可 以 在 第 一 个 处 理 者 后 面 建立 一 个 链 ， 也 就 是 责任 链 


来 处 理 请 求 ， 如 条 是 人 民 币 ， 好 ， 还 是 第 一 个 业务 逻辑 来 处 理 ;， 如 采 
征 美 元 ， 好 ， 传 递 到 第 二 个 业务 逻辑 来 处 理 ; 日 元 、 欧 元 .…… 这 些 都 
不 用 在 对 原 有 的 业务 逻辑 产生 很 大 改变 ， 通 过 扩展 实现 类 束 可 以 很 好 
地 解决 这 些 需 求 变更 的 问题 。 


责任 链 在 实际 的 项 目 中 使 用 也 是 比较 多 的 ， 我 曾经 做 过 这 样 一 个 
项 目 ， 界 面 上 有 一 个 用 户 注册 功能 ， 注 册 用 户 分 两 种 ， 一 种 是 VIP 用 
户 ， 也 就 是 在 该 单位 办 理 过 业务 的 ， 一 种 是 普通 用 户 ， 一 个 用 户 的 注 
册 要 填写 一 堆 信息 ，VIP 用 户 只 比 普 通用 户 多 了 一 个 输入 项 : VIP 序列 
号 。 注 册 后 还 需要 激活 ，VIP 和 普通 用 户 的 激活 流程 也 是 不 同 的 ，VIP 
是 自动 发 送 邮件 到 用 户 的 邮箱 中 就 算 激 活 了 ， 普 通用 户 要 发 送 短 信 才 
能 激活 ， 为 什么 呢 ? 获得 手机 号 码 以 后 好 发 广告 短信 啊 ! 项 目 组 就 采 
用 了 责任 链 模 式 ， 珊 管 从 前 台 传 递 过 来 的 是 VIP 用 户 信息 还 是 普通 用 户 
言 息 ， 统 一 传递 到 一 个 处 理 入 口 ， 通 过 责任 链 来 完成 任务 的 处 理 ， 类 
图 如 图 16-5 所 示 。 


Handler 
一 一 
+void HandleRequest(HashMap UserInfoMap) 


+void setNext(Handler handler) 
#yvoid response(HashMap UserInfoMap) 


CommonRegistev 


图 16-5 用 户 注册 类 图 


VIPRegistev 
| 
| | 


其 中 RegisterAction 是 继承 了 Strust2 中 的 ActionSupport， 实 现 HTTP 


传递 过 来 对 象 组 装 ， 组 装 出 一 个 HashMap 对 象 UserInfoMap， 传 递 给 


Handler 的 两 个 实现 类 ， 具 体 是 哪个 实现 类 来 处 理 的 ， 束 由 HashMap 上 
的 用 户 标 识 来 做 决定 了 ， 这 个 和 上 面 我 们 举 的 例子 很 类 似 ， 读 者 可 以 


自行 实现 。 


17.1 徘 亚 的 成 绩 


“中 庸 是 中 国 儒教 文化 的 集中 体现 ， 说 话 或 做 事情 都 不 能 太 直 
接 ， 需 要 有 技巧 。 比 如 谈话 ， 如 果 你 要 批评 某 个 人 ， 你 不 能 一 上 来 就 
说 他 这 做 得 不 对 ， 那 也 做 得 不 对 ， 你 要 先 肯 定 他 的 成 绩 ， 表 扬 一 下 优 
点 ; 然后 再 指出 不 足 ， 指 出 错误 的 地 方 ， 最 后 再 来 点 激励 ， 你 修改 了 
这 些 缺点 后 有 哪些 好 处 ， 比 如 你 能 市 更 多 的 小 兵 、 升 职 等 。 如 果 你 一 
上 来 束 是 一 屯 批评， 你 旺 办 看 ， 对 方 肯 定 是 不 服气 ， 甚 至 是 顶撞 你 
说 : “此 处 不 养 和 芭 ， 目 有 养 苑 处 "， 于 是 甩 门 而 去 。 


这 走 说 话 ， 做 事情 也 是 一 样 。 在 山寨 产品 流行 之 前 ， 假 货 也 是 比 
较 “ 盛 行 * 的 。 本 人 2002 年 严 了 一 部 手机 ， 当 时 老板 吹 得 天 化 乱 验 ， 承 
诺 这 部 手机 是 最 新 的 ， 我 看 着 也 像 ， 之 子 是 皆 新 的 ， 包 装 是 加 新 的 ， 
没有 任何 瑕 疲 ， 融 是 比 正品 便宜 了 很 多 ， 于 是 我 和 了 ， 因 为 缺 钱 啊 ! 
用 了 3 个 月 ， 坏 了 ， 送 修 检查 ， 结 果 诊 断 出 这 是 新 壳 装 旧 机 ， 我 党 ! 拿 
一 部 旧 手 机 的 线路 板 ， 找 个 新 的 外 这、 屏幕 、 包 装束 成 了 新 手机 ， 害 
人 不 浅 啊 | 


我 们 不 说 不 开心 的 事情 ， 今 天 以 什么 例子 为 开场 日 呢 ? 就 说 说 我 
上 小 学 的 灿 事 吧 。 我 上 小 学 的 时 候 学 习 成 绩 非常 老 ， 班 级 上 有 40 多 个 


同学 ， 我 基本 上 部 是 排 在 45 名 以 后 ， 按 照 老师 给 我 的 评价 整 是 :“ 不 是 
读书 的 料 ”。 但 是 我 父 茉 管 得 很 户 格 ， 明 知道 我 不 是 这 块 料 ， 还 十“ 赶 
鸭子 上 架 *"， 每 次 考 完 试 我 都 战 战 疡 世 ,， “人 竹 务 炒 肉 ” 是 肯定 少不了 的 ， 

但 古 能 少 点 束 少 点 吧 ， 因 为 肉 可 古 目 己 的 。 四 年 级 期 末 考 试 考 完 ， 学 
校 出 来 个 很 损 的 招 儿 (这 招 儿 现在 很 流行 的 ) ， 打 印 出 成 绩 单 ， 要 家 
长 签字 ， 然 后 才能 上 五 年 级 ， 我 那个 念 惧 呀 ， 不 过 也 就 是 几 秒 钟 的 时 
间 ， 玩 起 来 什么 都 筷 记 了 “。 我 们 做 如 构 ， 做 设计 ， 任 何 值得 我 们 回忆 

的 事件 都 可 以 通过 设计 记录 下 来 。 当 然 了 ， 这 份 成 绩 单 的 事情 也 是 可 

以 通过 类 图 表示 的 ， 如 图 17-1 所 示 。 


成 绩 单 有 两 个 方法 : 
report 描 述 成 绩 
sign 要 家 长 签字 


SchoolReport 


+vold report() 
+Vvold sign(String name) 


i 


FouthGrade SchoolReport 


> 
2 
2 
2 
+ 
2 


图 17-1 成 绩 单 类 图 


成 绩 单 的 抽象 类 ， 然 后 有 一 个 四 年 级 的 成 绩 单 实现 类 ，So Easy， 
我 们 先 来 看 抽象 类 ， 如 代码 清单 17-1 所 示 。 


代码 清单 17-1 抽象 成 绩 


public abstract class SchoolLReport { 
// 成 绩 单 主 要 展示 的 就 是 你 的 成 绩 情况 
public abstract void report(); 
// 成 绩 单 要 家 长 签字 ， 这 个 是 最 要 命 的 
public abstract void sign(); 


有 抽象 类 了 ， 我 们 再 来 看 看 具体 的 四 年 级 成 绩 
FouthGradeSchoolReport， 如 代码 清单 17-2 所 示 。 


代码 清单 17-2 四 年 级 成 绩 单 


public class FouthGradeSchoolReport extends SchoolReport { 
// 我 的 成 绩 单 
public void report() { 
// 成 绩 单 的 格式 是 这 个 样子 的 
System.out .print1ln(" 苯 敬 的 XXX 家 长 :")， 
System.out .printJln(” ...... ys 
System,out,println(" 语文 62 数学 65 体育 98 上 自然 


System.out.printJln(” ....... ") 
System.out.println(" 家 长 签名 : 


} 

// 家 长 签名 

public void sign(String name) { 
System.out.println(" 家 长 签名 为 : "+name ) ; 

} 


成 绩 单 出 来 ， 你 别 看 什么 62、65 之 类 的 成 绩 ， 你 要 知道 ， 在 小 学 
低 于 90 分 基本 上 就 是 中 下 等 了 ， 斐 月 呀 ， 爱 学 习 的 人 哗 束 那么 多 ! 起 
么 着 ， 那 我 把 这 个 成 绩 单 给 老爷 看 看 ? 好 ， 我 们 修改 一 下 类 图 ， 成 绩 
单 给 老 多 看 ， 如 图 17-2 所 示 。 


成 绩 单 有 两 个 方法 : 
report 描 述 成 绩 


SchoolReport 
| 
+void report() 

+void sign(String name) 


Sign 要 家 长 签字 


四 年级 的 成 绩 昌 人 FouthGrade SchoolReport 
级 的 成 绩 单 人 -= 
一 一 


图 17-2 老 爸 查看 成 绩 单 类 图 


Father 


老 爸 开始 看 成 绩 单 ， 这 个 成 绩 单 可 是 最 真实 的 ， 啥 都 没有 动 过 ， 
原装 ，Father 类 如 代码 清单 17-3 所 示 。 


代码 清单 17-3 老 爸 查看 成 绩 


public class Father { 
public static void main(String[] args) { 
// 把 成 绩 单 拿 过 来 
SchoolReport sr = new FouthGradeschoolReport(); 
// 看 成 绩 单 
sr.report(); 
// 签 名 ? 休想 ! 


一 


运行 结果 如 下 : 


尊敬 的 XXX 家 长 : 


语文 62 数学 65 体育 98 自然 63 


家 长 签名 : 


束 这 成 绩 还 要 我 签 子 ?|! 老 爸 束 开 始 找 扫 偶 ， 我 开始 做 准备 : 深 
呼吸， 绷 芭 肌肉 ， 提 臂 收 腹 。 哈 哈 ， 痒 运 的 是 ， 这 个 不 是 当时 的 真实 
情况 ， 我 没有 直接 把 成 绩 单 区 给 老 爸 ， 而 是 在 区 给 他 之 前 做 了 点 技术 
工作 ， 我 要 把 成 绩 单 封装 一 下 ， 封 装 分 类 两 步 来 实现 ， 如 下 所 示 。 


e 汇报 最 高 成 绩 


跟 老 爸 说 各 个 科目 的 最 高 分 ， 语 文 最 高 是 5， 数 学 是 78， 目 然 是 
80， 然 后 老 爸 觉得 我 的 成 绩 与 最 高 分 数 相 差不多 ， 考 的 还 是 不 错 的 
星 ! 这 个 是 实情 ， 但 是 不 知道 古 什 么 原因 ， 反 正 期 末 考 试 都 考 得 不 起 
么 样 ， 但 是 基本 上 都 集中 在 70 分 以 上 ， 我 这 60 多 分 基本 上 还 古朴 属 的 
角色 。 


e 汇报 排名 情况 


在 老 爸 看 完成 绩 单 后 ， 和 后 诉 他 我 在 全 班 排 第 38 名 ， 这 个 也 是 实 
情 ， 为 险 呢 ?有 将 近 十 个 同学 退学 了 ! 这 个 情况 我 是 不 会 说 的 。 不 知 
道 古 不 是 当时 第 一 次 发 成 绩 单 时 学 校 没 有 考虑 清楚 ， 没 有 写 上 忌 共有 
多 少 同学 ， 排 第 几 名 ， 反 正 生 被 我 逢 了 个 空子 。 


那 修饰 是 说 完了 ， 我 们 看 看 类 图 如 何 修改 ， 如 图 17-3 所 示 。 


成 绩 年 有 两 个 方法 : SchoolReport 
report 描 述 成 绩 


sign 要 家 长 签字 +void report() 


+void sign(Strng name) 


FouthGrade SchoolReport 


四 年 级 的 成 绩 单 、 


SugarFouthGrade SchoolReport 


午 写 report 方 法 

先 调 用 两 个 私有 方法 -void reportHighScore() 
-Vold reportSort() 

+void report() 


Father 


图 17-3 修饰 成 绩 


我 想 这 十 大 家 最 容易 想到 的 类 图 ， 通 过 直接 增加 了 一 个 于 类， 重 
写 report 方 法 ， 很 容易 地 解决 了 这 个 问题 ， 是 不 是 这 样 ? 是 的 ， 这 确实 
征 一 个 比较 好 的 办 法 ， 我 们 来 看 具体 的 实现 ， 如 代码 清单 17-4 所 示 。 


代码 清单 17-4 修饰 成 绩 单 


public class SugarFouthGradeSchoolReport extends 


FouthGradeSchoolReport { 
// 首 先 要 定义 你 要 美化 的 方法 ， 先 给 老爷 说 学 校 最 高 成 绩 
private void reportHighScore( ){ 
3 自然 


System.out .println(" 这 次 考试 语文 最 高 是 75， 数 学 是 78 ， 
是 80"); 
} 
// 在 老 爸 看 完毕 成 绩 单 后 ， 我 再 汇报 学 校 的 排名 情况 


private void reportSort( ){ 
System.out.println(" 我 是 排名 第 38 名 .,."); 


EFE 变 更 ， 那 所 以 要 重 写 父 类 


} 
// 由 于 沪 报 的 内 容 已 经 发 9 


@Override 

public void report()t{ 
this.reportHighScore(); // 先 说 最 高 成 绩 
super .report(); // 然 后 老 爸 看 成 绩 单 
this,reportSort()， // 然 后 告诉 老 爸 学 习 学 校 排名 


然后 对 Father 类 稍 做 修改 就 可 以 看 到 美化 后 的 成 绩 单 ， 如 代码 清单 
17-5 所 示 。 


代码 清单 17-5 老爷 查看 修饰 后 的 成 绩 单 


public class Father { 
public static void main(String[] args) { 

// 把 美化 过 的 成 绩 单 拿 过 来 
SchoolReport sr= new SugarFouthGradeSchoolReport(); 
// 看 成 绩 单 
sr.report(); 
// 然 后 老爷 ， 一 看 ， 很 开心 ， 束 签名 了 
sr .sign(" 老 三 "); // 我 叫 小 三 ， 老 爸 当然 叫 老 三 


证 


运行 结果 如 下 所 示 : 


这 次 考试 语文 最 高 是 75， 数 学 是 78， 自 然 是 80 


尊敬 的 XXX 家 长 : 


语文 62 数学 65 体育 98 自然 63 


通过 继承 确实 能 够 解决 这 个 问题 ， 老 爸 看 成 绩 单 很 开心 ， 然 后 束 
给 签字 了 ， 但 现实 的 情况 是 很 复杂 的 ， 可 能 老 爸 听 我 汇报 最 高 成 绩 
后 ， 束 直接 乐 开 化 了 ， 直 接 签 名 了 ， 后 面 的 排名 束 没 必要 看 了 ， 或 首 
老 爸 要 先 看 排名 情况 ， 那 怎么 办 ? 继续 扩展 ?你 能 扩展 多 少 个 类 ?这 
还 是 一 个 比较 简单 的 场景 ， 一 旦 需要 装饰 的 条 件 非常 多 ， 比 如 20 个 ， 
你 还 通过 继承 来 解决 ， 你 想象 的 子 类 有 多 少 个 ”你 是 不 是 马上 吕 要 衣 
并 了 |! 


好 ， 你 也 看 到 通过 继承 情况 确实 出 现 了 问题 ， 类 爆炸 ， 类 的 数量 
激增 ， 光 写 这 些 类 不 标 死 你 才 怪 ， 而 且 还 要 想 想 以 后 维护 怎么 办 ， 谁 
愿意 接收 这 么 一 大 摊 本 质 相 似 的 代码 维护 工作 ? 并 且 在 面向 对 象 的 设 
计 中 ， 如 果 超 过 两 层 继 承 ， 你 就 应 该 想 想 是 不 是 出 设计 问题 了 ， 是 不 
年 应 该 重新 找 一 条 康 庄 大 道 了 ， 这 走 经 验 值 ， 不 是 什么 绝对 的 ， 继 承 
层次 越 多 以 后 的 维护 成 本 越 多 ， 问 题 这 么 多 ， 那 去 么 办 ? 好 办 ， 我 们 
定义 一 批 专门 负责 装饰 的 类 ， 然 后 根据 实际 情况 来 决定 是 否 需要 进行 
淡 俩 ， 类 图 稍 做 修正 ， 如 图 17-4 所 示 。 


SchoolReport 
+vold report() 
Hvoid sign(String name) 
+Decorator(SchoolReport sr) 


+Volid report() 
+sign(String name) 


HighScore Decorator SortDecorator 


图 17-4 增加 专门 的 萎 师 类 网 


增加 一 个 抽象 类 和 两 个 实现 类 ， 其 中 Decorator 的 作用 是 封闭 
SchoolReport 类 ， 如 末 大 家 还 记得 代理 模式 ， 那 么 很 容易 看 懂 这 个 类 
图 ， 装 饰 类 的 作用 也 就 是 一 个 特殊 的 代理 类 ， 真 实 的 执行 者 还 是 被 代 
理 的 角色 FouthGradeSchoolReport， 如 代码 清单 17-6 所 示 。 


代码 清单 17-6 修饰 的 抽象 类 


public abstract class Decorator extends SchoolReport{ 
// 首 先 我 要 知道 是 哪个 成 绩 单 
private SchoolReport sr; 
// 构 造 画 数 ， 传 递 成 绩 单 过 来 
public Decorator(SchoolReport sr)t{ 


this.sr = sr; 


} 

// 成 绩 单 还 是 要 被 看 到 的 

public void report()t{ 
this.sr.report(); 


} 

// 看 完 还 是 要 签名 的 

public void sign(String name)t{ 
this.sr.sign(name); 

} 


看 到 没 ， 效 饰 类 还 是 把 动作 的 执行 委托 给 需要 装饰 的 对 象 ， 
Decorator 抽 和 象 类 的 目的 很 简单 ， 就 是 要 让 子 类 来 封 逆 SchoolReport 的 子 
类 ， 和 怎么 封 狂 ? 重 写 report 方 法 ! 先 看 HighScoreDecorator 实 现 类 ， 如 代 
码 清单 17-7 所 示 。 


代码 清单 17-7 最 高 成 绩 修 饰 


public class HighScoreDecorator extends Decorator { 
// 构 造 函 数 
public HighScoreDecorator(SchoolReport sr)t{ 
super (sr); 


} 
// 我 要 汇报 最 高 成 绩 
private void reportHighScore(){ 
System,.out ,println(" 这 次 考试 语文 最 高 是 75， 数 学 是 78， 自 然 


是 89" ) ; 

} 

// 我 要 在 老 和 从 看 成 绩 单 前 告诉 他 最 高 成 绩 ， 否 则 等 他 一 看 ， 束 抢 起 扫 蜗 接 我 ， 我 
哪里 还 有 机 会 说 啊 

Q@Override 


public void report(){ 
this.reportHighScore(); 
super .report(); 


重 写 了 report 方 法 ， 先 调用 具体 凌 炳 类 的 装饰 方法 
reportHighScore， 然 后 再 调用 具体 构件 的 方法 ， 我 们 再 来 看 怎么 汇报 学 
校 排序 情况 SortDecorator 代 码 ， 如 代码 清单 17-8 所 示 。 


代码 清单 17-8 排名 情况 修饰 


public class SortDecorator extends Decorator { 
// 构 造 函 数 
public SortDecorator(SchoolReport sr)t{ 
super (sr); 
} 


// 告 诉 老 爸 学 校 的 排名 情况 
private void reportSort( ){ 
System.out.print1Ln(" 我 是 排名 第 38 名 . . .") ) 


} 
// 老 爸 看 完成 绩 单 后 再 告诉 他 ， 加 强 作 用 
@Override 
public void report()t{ 
super .report(); 
this.reportSort(); 


我 准备 好 了 这 两 个 强力 的 修饰 工具 ， 然 后 就 “ 毫 不 县 惧 ” 地 把 成 绩 
单 交 给 老 爸 ， 看 看 老 爸 怎么 看 成 绩 单 的 ， 如 代码 请 单 17-9 所 示 。 


代码 清单 17-9 老爷 查看 修饰 后 的 成 绩 


public class Father { 

public static void main(String[] args) { 
// 把 成 绩 单 拿 过 来 
SchoolReport sr; 
// 原 装 的 成 绩 单 
sr = new FouthGradeSchoolReport(); 
// 加 了 最 高 分 说 明 的 成 绩 单 
sr = new HighScoreDecorator(sr); 
// 又 加 了 成 绩 排 名 的 说 明 


sr = new SortDecorator(sr); 


// 看 成 绩 单 

sr.report(); 

// 然 后 老 爸 一 看 ， 很 开心 ， 就 签名 了 
sr.SsSign(" 老 三 "); // 我 叫 小 三 ， 老 爸 当然 叫 老 三 


老 爸 一 看 成 绩 单 ， 听 我 这 么 一 这 ， 非 党 开 心 ， 儿 子 有 进步 呀 ， 从 

40 多 名 进步 到 30 多 名 ， 进 步 很 大 ， 躲 过 了 一 顿 海 刷 。 想 想 看 ， 如 果 我 

还 要 增加 其 他 的 修饰 条 件 ， 是 不 十 束 非 党 容易 了 ， 只 要 实现 Decorator 
类 束 可 以 了 ! 这 吏 是 痛 饰 模式 。 


17.2 竣 师 模式 的 定义 


装饰 模式 (Decorator Pattern) 是 一 种 比较 常见 的 模式 ， 其 定义 如 
下 : Attach additional responsibilities to an object dynamically keeping the 
same interface.Decorators provide a flexible alternative to subclassing for 
extending functionality. 《动态 地 给 一 个 对 象 添 加 一 些 额 外 的 职责 。 就 增 
加 功能 来 说 ， 装 饰 模 式 相 比 生 成 子 类 更 为 灵活 。) 


淡 饰 模式 的 通用 类 图 如 图 17-5 所 示 。 


Component 


component 


+Operation() 


Decorator 


ConcreateComponent 


ConcreteDecorator 


一 = 一 2 

| 
图 17-5 雄师 模式 的 通用 类 图 

在 类 图 中 ， 有 四 个 角色 需要 说 明 : 

@ Component 抽 和 象 构件 


Component 是 一 个 接口 或 者 是 抽象 类 ， 就 是 定义 我 们 最 核心 的 对 
象 ， 也 就 是 最 原始 的 对 象 ， 如 上 面 的 成 绩 单 。 


注意 ”在 装饰 模式 中 ， 必 然 有 一 个 最 基本 、 最 核心 、 最 原始 的 接 
口 或 抽象 类 充当 Component 抽 象 构件 。 


e ConcreteComponent 具体 构件 


ConcreteComponent 是 最 核心 、 最 原始 、 最 基本 的 接口 或 抽象 类 的 
实现 ， 你 要 装饰 的 就 是 它 。 


e@ Decorator 装 饰 角色 


一 般 是 一 个 抽象 类 ， 做 什么 用 呢 ? 实现 接口 或 者 抽象 方法 ， 它 里 
面 可 不 一 定 有 抽象 的 方法 呀 ， 在 它 的 属性 里 必然 有 一 个 private 变 量 指向 
Component 抽 象 构件 。 


e 具体 竣 师 角色 


ConcreteDecoratorA 和 ConcreteDecoratorB 是 两 个 具体 的 装饰 类 ， 你 
要 把 你 最 核心 的 、 最 原始 的 、 最 基本 的 东西 装饰 成 其 他 东西 ， 上 面 的 
例子 就 是 把 一 个 比较 平庸 的 成 绩 单 装饰 成 家 长 认可 的 成 绩 单 。 


淡 饰 模式 的 所 有 角色 都 已 经 解释 完毕 ， 我 们 来 看 看 如 何 实 现 ， 先 
看 抽象 构件 ， 如 代码 清单 17-10 所 示 。 


代码 清单 17-10 抽象 构件 


public abstract class Component { 
// 抽 象 的 方法 
public abstract void operate( ) ， 


具体 构件 如 代码 清单 17-11 所 示 。 


代码 清单 17-11 具体 构件 


public class ConcreteComponent extends Component { 
// 具 体 实 现 
@Override 
public void operate() { 
System.out.printJln("do Something"); 


洲 饰 角色 通 季 十 一 个 抽象 类 ， 如 代码 清单 17-12 所 示 。 


代码 清单 17-12 抽象 装饰 者 


public abstract class Decorator extends Component { 
private Component component = null; 
// 通 过 构造 画 数 传递 被 修饰 者 
public Decorator(Component _component){ 
this.component = _component,; 


} 

// 委 托 给 被 修饰 者 执行 

@Override 

public void operate() { 
this.component .operate( ) ; 


当然 了 ， 肴 只 有 一 个 装饰 类 ， 则 可 以 没有 抽象 疼 饰 角色 ， 直 接 实 
色 妈 可。 具体 的 婆 饰 类 如 代码 清单 17-13 所 示 。 


党 
部 
I 
= 
下 


代码 清单 17-13 具体 的 装饰 类 


public class ConcreteDecorator1 extends Decorator { 
// 定 义 被 修饰 者 
public ConcreteDecorator1(Component _component)t{ 
super(_component ); 


} 

// 定 义 自己 的 修饰 方法 

private void method1i()t{ 
System.out.println("method1 修饰 ") ; 

} 


// 重 写 父 类 的 0peration 方 法 
public void operate( ){ 
this.method1( ); 
super .operate( ); 


) 


public class ConcreteDecorator2 extends Decorator { 
// 定 义 被 修饰 者 
public ConcreteDecorator2(Component _component)t{ 
super(_component ); 


} 

// 定 义 自己 的 修饰 方法 

private void method2()t{ 
System.out.println("method2 修 饰 "); 


} 

// 重 写 父 类 的 0peration 方 法 
public void operate( ){ 
super .operate( ); 
this.method2(); 


注意 ”原始 方法 和 装饰 方法 的 执行 顺序 在 具体 的 装饰 类 是 国定 
的 ， 可 以 通过 方法 重 载 实现 多 种 执行 顺序 。 


我 们 通过 Client 类 来 模拟 高 层 模块 的 耦合 关系 ， 看 看 装饰 模式 是 如 
何 运行 的 ， 如 代码 清单 17-14 所 示 。 


代码 清单 17-14 场景 


public class Client { 
public static void main(String[] args) { 

Component component = new ConcreteComponent(); 
// 第 一 次 修饰 

component = new ConcreteDecorator1(component ) ; 
// 第 二 次 修饰 

component = new ConcreteDecorator2(component); 
// 修 饰 后 运行 

component ,operate( ); 


17.3 装饰 模式 应 用 
17.3.1 装饰 模式 的 优点 


e 装饰 类 和 被 装饰 类 可 以 独立 发 展 ， 而 不 会 相互 粳 合 。 换 句 话 
说 ，Component 类 无 须知 道 Decorator 类 ，Decorator 类 是 从 外 部 来 扩展 
Component 类 的 功能 ， 而 Decorator 也 不 用 知道 具体 的 构件 。 


e 装饰 模式 是 继承 关系 的 一 个 蔡 代 方案 。 我 们 看 装饰 类 
Decorator， 不 管 装 饰 多 少 层 ， 返 回 的 对 象 还 是 Component， 实 现 的 还 
是 is-a 的 关系 。 


e 闭 钱 模式 可 以 动态 地 扩展 一 个 实现 类 的 功能 ， 这 不 需要 多 说 ， 
痛 饰 模式 的 定义 吏 征 如 此 。 


17.3.2 装饰 模式 的 缺点 


对 于 装饰 模式 记 住 一 点 就 足够 了 : 多 层 的 逆 饰 是 比较 复杂 的 。 为 
什么 会 复杂 呢 ? 你 想 想 看 ， 束 像 剥 立 苞 一 样 ， 你 剥 到 了 最 后 才 发 现 是 
最 里 层 的 法 饰 出 现 了 问题 ， 想 象 一 下 工作 量 吧 ， 因 此 ， 尺 量 减少 狠 饰 
类 的 数量 ， 以 便 降 低 系 统 的 复杂 度 。 


17.3.3 雄师 模式 的 使 用 场景 


e 需要 扩展 一 个 类 的 功能 ， 或 给 一 个 类 增加 附加 功能 。 


e 需要 动态 地 给 一 个 对 象 增加 功能 ， 这 些 功 能 可 以 再 动态 地 撤 
销 。 


e 需要 为 一 批 的 兄 第 类 进行 改装 或 加 流 功 能 ， 当 然 是 首选 洲 饰 模 
式 0 


17.4 最 住 实 中 


装饰 模式 是 对 继承 的 有 力 补 充 。 你 要 知道 继承 不 是 万 能 的 ， 继 承 
可 以 解决 实际 的 问题 ， 但 是 在 项 目 中 你 要 考虑 诸如 易 维 护 、 易 扩展 、 
易 复 用 等 ， 而 且 在 一 些 情况 下 (比如 上 面 那个 成 绩 单 例子 ) 你 要 是 用 
继承 束 会 增加 很 多 子 类 ， 而 且 灵 活性 非常 产 ， 那 当然 维护 也 不 容易 
了 ， 也 就 是 说 装饰 模式 可 以 替代 继承 ， 解 决 我 们 类 膨胀 的 问题 。 同 
时 ， 你 还 有 要 知 道 继承 是 静态 地 给 类 增加 功能 ， 而 装饰 模式 则 是 动态 地 
增加 功能 ， 在 上 面 的 那个 例子 中 ， 我 不 想 要 SortDecorator 这 层 的 封装 
也 很 商 单 ， 于 是 直接 在 Father 中 去 掉 束 可 以 了 ， 如 采 你 用 继承 殉 必 须 
修改 程序 。 


痛 饰 模式 还 有 一 个 非常 好 的 优点 : 扩展 性 非常 好 。 在 一 个 项 目 
中 ， 你 会 有 非常 多 的 因素 考虑 不 到 ， 特 别 古 业务 的 变更 ， 不 时 地 冒 出 
一 个 需求 ， 尤 其 是 提出 一 个 令 项 目 大 量 延 迟 的 需求 时 ， 那 种 心情 是 相 
当 的 难受 ! 装饰 模式 可 以 给 我 们 很 好 的 帮助 ， 通 过 装饰 模式 重 狐 封闭 
一 个 类 ， 而 不 是 通过 继承 来 完成 ， 人 简单 点 说 ， 三 个 继承 关系 Father、 
Son、GrandSon 三 个 类 ， 我 要 在 Son 类 上 增强 一 些 功 能 怎么 办 ? 我 想 你 
会 坚决 地 顶 回去 ! 不 允许 ， 对 了 ， 为 什么 呢 ? 你 增强 的 功能 是 修改 
Son 关 中 的 方法 吗 ? 增加 方法 吗 ? 对 GrandSon 的 影响 呢 ? 特别 是 
GrandSon 有 多 个 的 情况 ， 你 会 怎么 办 ? 这 个 评估 的 工作 量 束 够 你 受 


的 ， 所 以 这 是 不 允许 的 ， 那 还 是 要 解决 问题 的 呀 ， 怎 么 办 ? 通过 建立 
SonDecorator 类 来 修饰 Son， 相 当 于 创建 了 一 个 新 的 类 ， 这 个 对 原 有 程 
序 没有 变更 ， 通 过 扩展 很 好 地 完成 了 这 次 变更 。 


第 18 划 策略 模式 


18.1 刘备 江东 楼 妻 ， 赵 云 他 容易 吗 


在 二 国 演义 中 ， 我 最 佩服 诸 裔 腕 的 地 方 不 古 因为 他 未 出 茅 庐 而 有 
三 分 天 下 的 预测 ， 也 不 是 他 在 赤壁 侯 战 中 借 东 风 的 法 术 ， 更 不 是 他 七 
擒 七 纵 孟 获 的 策略 。 那 是 什么 呢 ? 是 他 “ 气 死 周 瑜 ， 驾 死 王朗 ”的 气度 
和 风范 ! 想 想 看 ， 你 用 “ 气 * 能 把 一 个 轮胎 打 爆 ， 用 “ 气 ” 枪 能 够 把 路 灯 打 
人 雄 ， 但 是 要 把 跟 你 没有 任何 血 毕 关 系 的 人 气 死 有 多 困难 呀 ， 更 何况 是 


周瑜 这 种 稍 慧 型 人 物 ! 


在 诸多 完 气 周瑜 的 过 程 中 ， 有 一 件 事 情 : 那 束 是 周瑜 赔 了 夫人 又 
折 兵 这 件 事 情 。 事 情 经 过 是 这 样 的 : 孙权 看 刘备 有 雄 起 之 意 ， 杀 有 是 不 
能 杀 了 ， 那 会 邦 天 下 人 唾弃 ， 束 想 个 招 儿 挫 他 一 下 ， 那 有 什么 办 法 
呢 ? 孙权 有 个 妹妹 一 一 孙 尚 香 ， 准 备 招 刘备 做 女婿 ， 然 后 孙权 想 办 法 
把 刘备 软 公 起来， 孙权 的 想法 还 是 很 单纯 的 嘛 ， 融 是 不 让 你 刘备 回 西 
川 ， 然 后 我 东 吴 想 干 啥 束 干 哈 ， 夺 荆州 ， 春 西川 也 不 是 不 可 能 的 。 东 
吴 的 想法 是 好 的 ， 无 奈 中 间 多 了 智谋 无 敌 的 诸葛 亮 ， 他 早 就 预测 了 东 
吴 有 此 招数 ， 于 是 在 刘备 去 东 吴 招 茶 之 前 ， 特 授 以 伴 即 赵云 二 个 饥 
宫 ， 说 是 按 天 机 拆 开 解决 环 手 问题 。 


这 三 个 妙计 分 别 是 : 找 乔 国 老 帮 忙 (也 就 是 走后门 了 ) ， 求 吴 国 
太 放 行 (诉苦 ) 以 及 孙 夫 人 断后 ， 对 这 三 个 妙计 不 熟悉 的 读者 可 以 去 
温习 一 下 《三 国 演义 》， 这 里 就 不 多 说 了 。 想 想 看 ， 这 三 个 计谋 有 什 
么 相似 之 处 ， 他 们 都 是 告诉 赵云 要 怎么 执行 ， 也 就 是 说 这 三 个 计 谍 都 
有 一 个 方法 是 执行 ， 具体 执行 什么 内 容 ， 每 个 计谋 当然 不 同 了 ， 分 析 
到 了 这里， 我们 是 不 是 就 有 这 样 一 个 设计 思路 : 三 个 妙计 应 该 实现 的 是 
同一 个 接口 ? 聪明 ! 古 的， 我 们 来 看 类 图 ， 如 图 18-1 所 示 。 
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图 18-1 三 个 策略 类 图 


这 是 非常 简单 的 类 图 ， 在 这 个 场景 中 的 三 个 主要 角色 都 已 经 有 
了 ， 每 个 妙计 都 提供 了 一 个 可 执行 的 方法 ， 我 们 先 来 看 接口 ， 如 代码 
清单 18-1 所 示 。 


代码 清单 18-1 妙计 接口 


public interface IStrategy { 
// 每 个 锦 赛 妙计 都 是 一 个 可 执行 的 算法 
public void operate() 


接口 很 简单 ， 定 义 了 一 个 方法 operate， 每 个 妙计 都 是 可 执行 的 ， 
否则 那 叫 什么 妙计 ， 我 们 和 看 第 一 个 妙计 一 一 找 乔 国 老 开 后 [ 门 ， 如 代 
码 清单 18-2 所 示 。 


代码 清单 18-2 乔 国 老 开 后 门 


public class BackDoor implements IStrategy { 
public void operate() { 
System.out.println(" 找 乔 国 老 帮 忙 ， 让 吴 国 太 给 孙权 施加 压 
力 "); 
} 


} 


第 二 个 妙计 是 找 呈 国 太 尖 诉 ， 企 图 给 目 己 开绿灯 ， 如 代码 清单 18-3 
所 示 。 


代码 清单 18-3 吴 国 太 开绿灯 


public class GivenGreenLight implements IStrategy { 
public void operate() { 
System.out.println(" 求 吴 国 太 开绿灯 , 放行 !")，; 


第 三 个 妙计 是 在 逃跑 的 时 候 ， 让 新 妨 子孙 夫人 断后 ， 谁 来 砍 谁 ， 
这 是 非常 好 的 主意 ， 如 代码 清单 18-4 所 示 。 


代码 清单 18-4 孙 夫 人 断后 


public class BlockEnemy implements IStrategy { 


public void operate() { 


System.out.printlLn(" 孙 夫人 断后 ， 挡 住 追 兵 ") ， 


在 这 个 场景 中 ， 三 个 妙计 部 有 了 ， 那 还 缺少 两 个 配角 : 第 一 ， 妙 


计 肯 定 要 放 到 一 个 地 方 吧 ， 这 么 重要 的 东西 要 保管 蚜 ， 也 整 古 承 狐 妙 
计 的 锦 赛 ， 所 以 份 称 锦 赛 妙 计 嘛 ;第 二 ， 这 些 妙计 都 要 有 一 个 执行 

吧 ， 是 谁 ?当然 是 赵云 了 ， 妙 计 是 小 亮 给 的 ， 执 行者 是 赵云 。 赵 云 号 
是 一 个 干 活 的 人 ， 从 锦 宫 中 取出 妙计 ， 执 行 ， 然 后 获胜 。 过 程 非常 清 


晰 ， 我 们 把 完整 的 过 程 设 计 出 来 ， 如 图 18-2 所 示 。 


在 类 图 中 增加 了 一 个 Context 封 装 类 (也 就 是 饥 蚜 ) ， 
淡 二 个 菏 上 略 ， 方 便 赵 云 使 用 ， 我 们 来 看 Context 代 码 ， 如 代码 清单 18-5 
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.| IStrategy 
UU 


Di 


+Vold operate() 


ivenGreenLight 


Ee 
[LE 
Eee = NE = 


找 乔 国 老 开 后 门 


吴 国 太 开绿灯 、 


yy | 
+Context(IStrategy Strategy) 
+Vold operate() 


图 18-2 完整 类 图 


代码 清单 18-5 锦 时 


public class Context { 
// 构 造 画 数 ， 你 要 使 用 哪个 妙计 
private IStrategy straegy; 
public Context(IStrategy strategy)t{ 
this.straegy = strategy; 


7 

// 使 用 计谋 了 ， 看 我 出 招 了 

public void operate(){ 
thls.straegy.operate() ， 

} 


过 构造 函数 把 策略 传递 进来 ， 然 后 用 operate0) 方 法 来 执行 相关 的 

策略 方法 。 三 个 妙计 有 了 ， 锅 赛 也 有 了 ， 人 然后 就 是 赵云 雄 超 赵 地 揣 着 

三 个 锦 赛 ， 拉 着 已 步 入 老年 行列 的 、 还 想 着 要 纯情 少女 的 刘 老 爷 子 去 

痪 了 。 嗨 ， 还 别 说 ， 小 亮 同志 的 三 个 妙计 还 真是 不 错 ， 如 代码 清单 
18-6 所 示 。 


代码 清单 18-6 使 用 计谋 


public class ZhaoYun { 

// 赵 云 出 场 了 ， 他 根据 诸葛 亮 给 他 的 交代 ， 依 次 拆 开 妙计 

public static void main(String[] args) { 
Context context,; 
// 刚 刚 到 匡 国 的 时 候 拆 第 一 个 
System.out .println("--- 刚 刚 到 吴 国 的 时 候 拆 第 一 个 ---"); 
context = new Context (new BackDoor()); // 拿 到 妙计 
context.,operate(); // 拆 开 执行 
System.out ， a 
// 刘 备 乐 不 思 蜀 了 ， 拆 第 二 
System,out ， Re 拆 第 二 个 了 ---"); 
context = new Context(new GivenGreenLight()); 
context ,operate(); // 执 行 了 第 二 个 锦 宫 


System.out.printin("\n nNnnNn\NnN NINN"); 

// 孙 权 的 小 兵 追 来 了 ， 咋 办 ? 拆 第 三 个 

System.out .printlLn("--- 孙 权 的 小 兵 追 来 了 ， 咋 办 ? 拆 第 三 个 - 
--"); 

context = new Context(new BlockEnemy()); 

context.operate(); // 孙 夫人 退兵 

System.out.printin("\n nn n\n NN\N"); 


我 们 来 看 看 这 段 故 事 ， 运 行 结 末 如 下 : 


-刚刚 到 匡 国 的 时 候 拆 第 一 个 --- 


找 乔 国 老 帮 忙 ， 让 吴 国 太 给 孙权 施加 压力 


-刘备 乐 不 思 易 了 ， 拆 第 二 个 --- 
求 吴 国 太 开 个 绿灯 ， 放 行 ! 
一- 孙权 的 小 兵 妃 来 了 ， 咋 办? 拆 第 三 个 --- 


孙 夫 人 断后 ， 挡 住 追 兵 


轧 ， 不错 ， 吏 这 三 招 ， 摘 得 孙权 是 “ 赔 了 夫人 又 折 兵 ”。 那 我 们 摘 
述 这 个 故事 的 过 程 融 生 策略 模式 。 


18.2 策略 模式 的 定义 


策略 模式 (Strategy Pattern) 是 一 种 比较 简单 的 模式 ， 也 叫做 政策 
模式 (Policy Pattern) 。 其 定义 如 下 : 


Define a family of algorithms,encapsulate each one,and make them 
interchangeable. \ 定 义 一 组 算法 ， 将 每 个 算法 都 封装 起 来 ， 并 且 使 它们 
之 间 可 以 互 换 。) 


这 个 定义 是 非常 明确 、 清 晰 的 , “定义 一 组 算法 ”， 看 看 我 们 的 三 
个 计谋 是 不 是 三 个 算法 ?“ 将 每 个 算法 都 封装 起 来 "， 封 装 类 Context 不 
就 是 这 个 作用 吗 ?“ 使 它们 可 以 互 换 * 当 然 可 以 互 换 了 ， 都 实现 是 相同 
的 接口 ， 那 当然 可 以 相互 转化 了 。 我 们 看 看 策略 模式 的 通用 类 图 ， 如 
图 18-3 所 示 。 


十 Strategy 


Context Strategy 


+Algorithmlnterface() 


+ContextInterface() 


ConcreteStrategy 


图 18-3 宽 略 模式 通用 类 图 


策略 模式 使 用 的 就 是 面向 对 象 的 继承 和 多 态 机 制 ， 非 常 容 易 理解 
和 和 掌握， 我们 再 来 看 看 录 上 略 模式 的 三 个 角色 : 


e Context 封 装 角 色 


它 也 叫做 上 下 文 角 色 ， 起 夭 上 局 下 封闭 作用 ， 屏 蔽 高 层 模块 对 策 
略 、 算 法 的 直接 访问 ， 封 次 可 能 存在 的 变化 。 


e Strategy 抽 象 策 略 角 色 


策略 、 算 法 家 族 的 抽象 ， 通 常 为 接口 ， 定 义 每 个 策略 或 算法 必须 
具有 的 方法 和 属性 。 各 位 看 书 可 能 要 问 了 ， 类 图 中 的 AlgorithmInterface 
征 什么 意思 ， 嘿 嘿 ，algorithm 十 “运算 法 则 ”的 意思 ， 结 合 起 来 意思 就 明 


园丁 肥 洁 


e ConcreteStrategy 上 有 具体 稼 略 角色 
实现 抽象 策略 中 的 操作 ， 该 类 含有 具体 的 算法 。 


我 们 再 来 看 策略 模式 的 通用 源码 ， 非 常 简 单 。 先 看 抽象 策略 角 
色 ， 它 是 一 个 非常 普通 的 接口 ， 在 我 们 的 项 目 中 就 是 一 个 普通 得 不 能 
再 普通 的 接口 了 ， 定 义 一 个 或 多 个 具体 的 算法 ， 如 代码 清单 18-7 所 示 。 


代码 清单 18-7 抽象 的 策略 角色 


public interface Strategy { 
// 策 略 模式 的 运算 法 则 
public void doSomething(); 


具体 策略 也 是 非常 普通 的 一 个 实现 类 ， 只 要 实现 接口 中 的 方法 就 
可 以 ， 如 代码 清单 18-8 所 示 。 


代码 清单 18-8 具体 策略 角色 


public class ConcreteStrategy1 implements Strategy { 
public void doSomething() { 
System,.out ,printlLn(" 有 具体 策略 1 的 运算 法 则 ") ， 


} 
public class ConcreteStrategy2 implements Strategy { 
public void doSomething() { 
System,.out ,printlLn(" 有 具体 策略 2 的 运算 法 则 ") ， 
} 


策略 模式 的 重点 距 是 封 汉 角 色 ， 它 是 借用 了 代理 模式 的 思路 ， 大 
家 可 以 想 想 ， 它 和 代理 模式 有 什么 差别 ， 差 别 就 是 策略 模式 的 封装 角 


色 和 被 封 狐 的 策略 类 不 用 是 同一 个 接口 ， 如 琳 是 同一 个 接口 那 束 成 为 
了 代理 模式 。 我 们 来 看 封 狠 角色， 如 代码 清单 18-9 所 示 。 


代码 清单 18-9 封闭 角色 


public class Context { 
// 抽 象 策 权 
private Strategy strategy = null; 
// 构 造 范 数 设 置 具 体 策 
public Context(Strategy _strategy)t{ 
this.strategy = _strategy; 
} 


// 封 装 后 的 策略 方法 
public void doAnythinig(){ 

this.strategy.doSomething(); 
} 


高 层 模块 的 调用 非常 简单 ， 知 道 要 用 哪个 策略 ， 产 生出 它 的 对 
象 ， 然 后 放 到 封装 角色 中 就 完成 任务 了 ， 如 代码 清单 18-10 所 示 。 


代码 清单 18-10 高 层 模 块 


public class Client { 

public static void main(String[] args) { 
// 声 明 一 个 具体 的 策 权 
Strategy strategy = new ConcreteStrategy1L( ) ; 
// 声 明 上 下 文 对 象 
Context context = new Context(strategy); 
// 执 行 封装 后 的 方法 
context .doAnythinig(); 


策略 模式 就 是 这 么 简单 ， 偷 着 乐 吧 ， 它 束 是 采用 了 面向 对 象 的 继 
承 和 多 态 机 制 ， 其 他 没什么 玄机 。 想 想 看 ， 你 真实 的 业务 环境 有 这 人 么 


简单 吗 ? 一 个 类 实现 多 个 接口 很 正 肖 ， 你 要 有 火眼金睛 看 清楚 哪个 接 


口 是 抽 和 象 策略 接口 ， 哪 些 是 和 策略 模式 没有 任何 关系 ， 这 就 是 你 作为 
系统 分 析 师 的 价值 所 在 。 


18.3 策略 模式 的 应 用 
18.3.1 策略 模式 的 优点 


e 算法 可 以 目 由 切换 


这 是 策略 模式 本 映 定义 的 ， 只 要 实现 抽象 策略 ， 它 束 成 为 策略 家 
族 的 一 个 成 员 ， 通 过 封 效 角色 对 其 进行 封 狐 ， 保 证 对 外 提供 “可 目 由 切 
换 ” 的 策略 。 


e 避免 使 用 多 重 条 件 判 晰 


如 果 没 有 策略 模式 ， 我 们 想 想 看 会 是 什么 样子 ? 一 个 策略 家 族 有 5 
个 策略 算法 ， 一 会 要 使 用 A 策略 ， 一 会 要 使 用 B 策 略 ， 怎 么 设计 呢 ? 使 
用 多 重 的 条 件 语句 ? 多 重 条 件 语句 不 易 维 护 ， 而 且 出 错 的 概率 大 大 增 
强 。 使 用 策略 模式 后 ， 可 以 由 其 他 模块 决定 采用 何 种 策略 ， 策 略 家 族 
对 外 提供 的 访问 接口 就 是 封装 类 ， 简 化 了 操作 ， 同 时 避免 了 条 件 语句 
判断 。 


e 扩展 性 恨 好 


这 甚至 都 不 用 说 是 它 的 优点 ， 因 为 它 太 明显 了 。 在 现 有 的 系统 
增加 一 个 策略 太 容易 了 ， 只 要 实现 接口 束 可 以 了 ， 其 他 都 不 用 修改 ， 


类 似 于 一 个 可 反复 拆 凶 的 插件 ， 这 大 大 地 符合 了 OCP 原 则 。 


18.3.2 稼 略 模式 的 缺点 


。 策略 类 数量 增多 


每 一 个 策略 都 吓 一 个 类 ， 复 用 的 可 能 性 很 小 ， 类 数量 增多 。 


e 所 有 的 策略 类 都 需要 对 外 骏 露 


上 层 模块 必须 知道 有 哪些 策略 ， 人 然后 才能 决定 使 用 哪 一 个 策略 ， 
这 与 迪 米 特 法 则 是 相 违 育 的 ， 我 只 是 想 使 用 了 一 个 策略 ， 我 插 什 么 殉 
要 了 解 这 个 策略 呢 ? 那 要 你 的 封 厂 类 还 有 什么 意义 ? 这 是 原装 寅 略 模 
式 的 一 个 缺点 ， 驻 运 的 是 ， 我 们 可 以 使 用 其 他 模式 来 修正 这 个 缺陷 ， 
如 工厂 方法 模式 、 代 理 模式 或 享 元 模式 。 


18.3.3 宋 略 模式 的 使 用 场景 


e 多 个 类 只 有 在 算法 或 行为 上 稍 有 不 同 的 场景 。 


e 算法 需要 目 由 切换 的 场景 。 


例如 ， 算 法 的 选择 是 由 使 用 者 决定 的 ， 或 者 算法 始终 在 进化 ， 特 
别 是 一 些 站 在 技术 前 治 的 行业 ， 连 业务 专家 都 无 法 给 你 保证 这 样 的 系 


统 规则 能 够 存在 多 长 时 间 ， 在 这 种 情况 下 策略 模式 是 你 最 好 的 助手 。 


e 需要 屏蔽 算法 规则 的 场景 。 


现在 的 科技 发 展 得 很 快 ， 人 脑 的 记忆 是 有 限 的 就 目前 来 说 是 有 
限 的) ， 太 多 的 算法 你 只 要 知道 一 个 名 字 就 可 以 了 ， 传 递 相关 的 数字 
进来 ， 反馈 一 个 运算 结果 ， 万 事 大 吉 。 


18.3.4 策略 模式 的 注意 事项 


如 有 果 系 统 中 的 一 个 策略 家 族 的 具体 策略 数量 超过 4 个 ， 则 需要 考虑 
使 用 混合 模式 ， 解 决策 略 类 膨胀 和 对 外 烘 露 的 问题 ， 否 则 日 后 的 系统 
维护 就 会 成 为 一 个 六 手 山芋 ， 谁 都 不 想 接 。 


18.4 案 略 模式 的 扩展 


先 给 出 一 道 小 学 的 题目 : 输入 3 个 参数 ， 进 行 加 减法 运算 ， 人 参数 中 
两 个 是 int 型 的 ， 剩 下 的 一 个 参数 是 String 型 的 ， 只 有 “+”、“-” 两 个 符号 
可 以 选择 ， 不 要 考虑 什么 复杂 的 校 验 ， 我 们 做 的 古 日 箱 测 试 ， 输 入 的 
束 古 标准 的 int 类 型 和 合 规 的 String 类 型 ， 各 位 大 侠 ， 想 想 看 ， 怎 么 做 ， 


有 非常 多 的 实现 方式 ， 我 今天 来 说 四 种 。 先 说 第 一 种 ， 写 一 个 
类 ， 然 后 进行 加 减法 运算 ， 类 图 也 不 用 画 了 ， 太 简单 了 ， 如 代码 清单 


18-11 所 示 。 


代码 清单 18-11 最 直接 的 加 减法 


public class Calculator { 
// 加 符号 
private final static String ADD_ SYMBOL = "+"; 
// 减 符号 
private final static String SUB_ SYMBOL = "-",; 
public int exec(int a,int b,String symbol)t{ 
int result =0; 
if(symbol.equals(ADD_SYMBOL)){ 
result = this.add(a, b); 
}else if(symbol.equals(SUB_ SYMBOL))E{ 
result = this.sub(a, b); 
} 


return result; 


} 

// 加 法 运算 

private int add(int a,int b)t{ 
return a+b ， 

} 


// 减 法 运 货 

private int sub(int ay int b)t{ 
return a-b; 

上 


算法 太 侧 单 了 ， 每 个 程序 员 都 会 写 。 再 写 一 个 场景 类 如 18-12 所 


尔 。 


代码 清单 18-12 场景 类 


public class Client { 
public static void main(String[|] args) { 

// 输 入 的 两 个 参数 是 数字 
int a = Integer.parseInt(args[0]); 
String symbol = args[1]; // 符 号 
int b = Integer.parseInt(args[2]); 
System.out.printlin(" 输 入 的 参数 

为 : "+Arrays， tostring(args)); 
// 生 成 个 运 运算 妖 
Calculator cal = new Calculator(); 
System.out.println(" 运 行 结果 为 : "+a + Symbol + b + 

"=" + cal.exec(a, b, symbol)); 


} 
} 


输入 3 个 参数 ， 分 别 是 100 + 200， 运 行 结 果 如 下 所 示 : 


输入 的 参数 为 : [100, +, 200] 


运行 结果 为 : 100+200=300 


个 方案 是 非常 简单 的 ， 能 够 解决 问题 ， 我 相信 这 有 是 大 家 最 容易 
想到 的 方案 ， 我 们 不 评论 这 个 方案 的 优 务 ， 等 把 四 个 方案 全 部 讲 完 
了 ， 你 目 己 殉 会 发 现 红 优 的 劣 。 


我 们 再 来 看 第 二 个 方案 ，Calculator 类 太 叶 了 ， 人 简化 算法 如 代码 清 
单 18-13 所 示 。 


代码 清单 18-13 简化 算法 
public class Calculator { 
// 加 符号 
private final static String ADD_ SYMBOL = "+"; 
// 减 符号 
private final static String SUB_ SYMBOL = "-"; 
public int exec(int a,int b,String symbol)t{ 
return symbol.equals(ADD_SYMBOL)?a+b:a-b; 
上 


这 也 非常 和 测 单 ， 束 是 一 个 三 目 运算 符 ， 确 实 简化 了 很 多 。 有 缺陷 
先 别管 ， 我 们 主要 讲 设 计 ， 你 在 实际 项 目 应 用 中 要 处 理 该 程序 中 的 缺 


该 方案 的 场景 类 与 方案 一 相同 ， 如 代码 清单 18-12 所 示 ， 运 行 结果 
也 相同 ， 不 再 玖 述 。 


我 们 再 来 思考 第 三 个 方 宁 ， 本 章 介 绍 策略 模式 ， 那 把 策略 模式 应 
用 到 该 需求 是 不 是 很 合适 啊 ? 是 的 ， 非 常 合适 ! 加 减法 就 古 一 个 具体 
的 策略 ， 非 常 简 单 ， 省 略 类 图 ， 直 接 看 源码 ， 我 们 先 来 看 抽象 集 略 ， 
定义 每 个 策略 必须 实现 的 方法 ， 如 代码 请 单 18-14 所 示 。 


代码 清单 18-14 引入 策略 模式 


Interface Calculator { 
public int exec(int a,int b); 


抽象 策略 定义 了 一 个 唯一 的 方法 来 执行 运算 。 至 于 具体 执行 的 是 
加 法 还 是 减法 ， 运 算 时 由 上 下 文 角色 决定 。 我 们 再 来 看 两 个 具体 的 策 
略 ， 如 代码 清单 18-15 所 示 。 


代码 清单 18-15 具体 策略 


public class Add implements Calculator { 
// 加 法 运 货 
public int exec(int a, int b) { 
return a+b; 
} 


public class Sub implements Calculator { 
// 诚 法 运 货 
public int exec(int a, int b) { 
return a-b; 
} 


封 竣 角色 的 贡 任 是 保证 策略 时 可 以 相互 敬 换 ， 如 代码 清单 18-15 所 


人 小 ° 


代码 清单 18-16 上 下 文 


public class Context { 
private Calculator cal = null; 
public Context(Calculator _cal)t{ 
this.cal = _cal; 


public int exec(int a,int b,String symbol)t{ 
return this.cal.exec(a, b); 
} 


代码 都 非常 商 单 ， 该 部 分 喊 不 再 增加 注释 信息 了 。 上 下 文 类 负责 
把 策略 封 玫 起 来 ， 具 体 怎 么 目 由 地 切换 策略 则 是 由 高 层 模块 负责 声明 
的 ， 如 代码 清单 18-17 所 示 。 


代码 清单 18-17 场景 类 


public class Client { 

// 加 符号 

public final static String ADD_SYMBOL = "+"; 

// 减 符号 

public final static String SUB_SYMBOL = "-"; 

public static void main(String[] args) 这 
// 输 入 的 两 个 参数 是 数字 
int a = Integer.parseInt(args[0]); 
String symbol = args[1]; // 符 号 
int b = Integer.parseIint(args[2]); 
System.out.printlin(" 输 入 的 参数 

为 : "+Arrays,toString(args))， 
// 上 下 文 
Context context = null; 
// 判 断 初始 化 哪 一 个 策略 
If(symbol,eduals(ADD_SYMBOL ) ) 攻 
context = new Context (new Add()); 
}else if(symbol.equals(SUB_ SYMBOL))E{ 
context = new Context(new Sub()); 

} 


System.out.println( "运行 结果 
为 : "+a+symbol+b+"="+context,.exec(a,b,symbol)); 


} 


运行 结果 与 方案 一 相同 。 我 们 想 想 看 ， 在 该 策略 模式 的 一 个 具体 
应 用 中 ， 我 们 使 用 Context 准 备 了 一 组 算法 (加 法 和 减法 ，， 并 封装 
起 来 ， 具 体 使 用 哪 一 个 策略 (加 法 还 是 减法 ) 则 由 上 层 模 块 声明 ， 这 
样 扩 展 性 非常 好 。 


现在 只 剩 最 后 一 个 方案 了 ， 一 般 最 后 出 场 的 都 是 重量 级 的 人 物 ， 

压 场 嘛 ! 那 束 请 出 我 们 最 后 一 个 重量 级 角色 ， 首 乐 啊 起 ， 一 个 黑 影 站 

定 舞 台中 央 ， 所 有 灯光 突然 察 焦 ， 主 角 绥 绥 择 起 涉 ， 它 就 古 一 一 策略 
枚 举 ! 我 们 来 看 看 其 真实 实力 ， 如 代码 清单 18-18 所 示 。 


代码 清单 18-18 策略 枚 举 


public enum Calculator { 
// 加 法 运 货 
ADD("+"){ 
public int exec(int a,int b)t{ 
return ar+b ， 
} 


SUB("-")t{ 
public int exec(int a,int b){ 
return a - b; 


} 

}; 

String value = ""， 

// 定 义 成 员 值 类 型 

private Calculator(String _value)t{ 
this.value = _value; 


} 

// 获 得 枚 举 成 员 的 值 

public String getValue(){ 
return this.value; 


// 声 明 一 个 抽象 画 数 


public abstract int exec(int a,int b); 


先 想 一 想 它 的 名 字 ， 为 什么 叫做 策略 枚 举 ? 枚 举 没 有 问题 ， 它 束 
征 一 个 Enum 类 型 ， 那 为 什么 又 叫做 策略 呢 ? 找 找 看 能 不 能 找到 策略 的 
影子 在 里 面 ? 征 的 ， 我 们 定义 了 一 个 抽象 的 方法 exec， 然 后 在 每 个 枚 


举 成 员 中 进行 了 实现 ， 如 果 不 实 现 会 怎么 样 呢 ? 你 试 试看 看 ， 不 实现 

该 方法 就 不 能 编译 ， 现 在 是 不 是 清楚 了 ? 把 原 有 定义 在 抽象 策略 中 的 
方法 移植 到 枚 举 中 ， 每 个 枚 举 成 员 承 成 为 一 个 具体 策略 。 简 单 吧 ， 总 
一 下 ， 策 略 枚 举 定 义 如 下 : 


全 是 二 全 


苹 一 个 浓缩 了 的 和 集 略 模式 的 枚 举 。 


当然 ， 读 者 可 能 要 反思 了 ， 我 使 用 内 置 类 也 可 以 实现 相同 的 功 
能 ， 写 一 个 Context 类 ， 然 后 把 抽象 策略 、 具 体 集 上 略 都 内 置 进去 ， 不 开 
可 以 解决 问题 了 ， 是 的 ， 可 以 解决 ,但 古 扩展 性 如 何 ? 可 读 性 如 何 ? 
代码 是 让 人 读 的 ， 然 后 才 是 让 机 器 执行 ， 别 把 顺序 搞 反 了 ! 


我 们 继续 完善 方案 四 ， 场 景 类 稍 有 改动 ， 如 代码 清单 18-19 所 示 。 


代码 清单 18-19 场景 类 


public class Client { 
public static void main(String[|] args) { 

// 输 入 的 两 个 参数 是 数字 
int a = Integer.parseInt(args[0]); 
String symbol = args[1]; // 符 号 
int b = Integer.parseInt(args[2]); 
System.out.printlin(" 输 入 的 参数 

为 : "+Arrays.toSstring(args)); 
System.out.printLn(" 运 行 结果 

为 : "+a+symbol+b+"="+Calculator .ADD.exec(a,b)); 


运行 结果 与 方案 一 相同 。 看 这 个 场景 类 ， 代 码 量 非常 少 ， 而 且 还 
有 一 个 显著 的 优点 : 真实 地 面向 对 象 ， 看 看 这 条 语句 


Calculator.ADD.exec(a, b) 
对 a 和 Pb 进 行 加 法 运算 


是 不 是 类 似 于 “ 拿 出 计算 器 〈Calculator) 
(ADD) ， 并 立刻 执行 (exec>， 这 与 我 们 日 常 接触 逻辑 是 不 是 非常 相 


口 尘 
人 入 贡 ! 


似 ， 这 也 正 是 我 们 架构 师 要 担当 的 终 
注意 ”策略 枚 举 是 一 个 非常 优秀 和 方便 的 模式 ,但 十 它 受 枚 举 类 
定 


型 的 限制 ， 每 个 枚 举 项 都 是 public、final 、static 的 ， 扩 展 性 受到 了 一 
的 约束 ， 因 此 在 系统 开发 中 ， 策 上 略 枚 举 一 般 担当 不 经 常 发 生变 化 的 角 


色 。 


18.5 最 住 实践 


策略 模式 是 一 个 非常 简单 的 模式 。 它 在 项 目 中 使 用 得 非常 多 ， 但 
它 单 独 使 用 的 地 方 号 比较 少 了 ， 因 为 它 有 致命 缺陷 : 所 有 的 策略 都 需 
要 又 露出 去 ， 这 样 才 方 便 客 户 端 决定 使 用 哪 一 个 策略 。 例 如 ， 在 例子 
中 的 赵云 ， 实 际 上 不 知道 使 用 哪个 策略 ， 他 只 知道 拆 第 一 个 锦 赛 ， 而 
不 知道 是 BackDoor 这 个 妙计 。 是 的 ， 诸 曾 有 党 已 经 在 规定 了 在 适当 的 场 
景 下 拆 开 指定 的 锦 寺 ， 我 们 的 策略 模式 只 是 实现 了 锦 赛 的 管理 ， 但 是 
我 们 没有 严格 地 定义 “适当 的 场景 " 拆 开 * 适 当 的 锦 赛 "， 在 实际 项 目 
中 ， 我 们 一 般 通 过 工厂 方法 模式 来 实现 策略 类 的 声明 ， 读 者 可 以 参考 
混 编 模式 。 


19.1 业务 发 展 一 一 上 帝 才 能 控制 


有 这 样 一 名 名言: “智者 和 干 虑 必 有 一 失 ， 昌 者 干 虑 必 有 一 得 ” 品 ， 
意思 是 说 不 管 多 聪明 的 人 ， 经 过 多 少 次 的 思考 ， 也 总 是 会 出 现 一 些微 
小 的 错误 ,，“ 知 着 ?部 是 如 此 ， 何 况 我 们 这 些 乎 良 之 卒 呢 ! 我 们 在 进行 
系统 开发 时 ， 不 管 之 前 的 可 行 性 分 析 、 和 需求 分 析 、 系 统 设 计 处 理 得 多 
么 完美 ， 总 会 在 关键 时 候 、 关 键 场合 出 现 一 些 “ 意 外 ”。 对 于 这 些 “ 意 
外 ”， 该 来 的 还 是 要 来 ， 躲 是 又 不 过 去 的 ， 那 我 们 怎么 来 弥补 这 些 “ 意 
外 "了 呢 ? 这 难 不 倒 我 们 的 设计 大 师 ， 他 们 创造 出 了 一 些 补 救 模式 ， 今 天 
我 们 束 来 讲 一 个 补救 模式 ， 这 种 模式 可 以 让 你 从 因 业 务 扩展 而 系统 
法 迅速 适应 的 否 恼 中 解 脐 而 出 。 


2004 年 我 带 了 一 个 项 目 ， 做 一 个 人 力 资 源 管 理 项 目 ， 该 项 目 是 我 
们 总 公司 发 起 的 ， 公 司 一 共有 700 多 号 人 。 这 个 项 目 还 是 比较 简单 的 ， 
分 为 三 大 模块 :人员 信 息 管理 、 新 酬 管理 、 职 位 管理 。 当 时 开发 时 业 
务 人 员 明 确 指 明 : 人 员 信 息 管理 的 对 象 是 所 有 员工 的 所 有 信息 ， 所 有 
的 员工 指 的 是 在 职 的 员工 ， 其 他 的 离职 的 、 退 休 的 暂 不 考虑 。 根 据 需 
求 我 们 设计 了 如 图 19-1 所 示 的 类 图 。 


<<Interface>> 
IUserInfo 
= 人 下 qq 
tString getUserName()() 


+Strng getHomeAddress() 


+String getMobile Number() 
tStrng getOfficeTeINumber() 
+Strng getJobPosition() 
+String getHome TeINumber() 


UserInfo 
| 
| 


图 19-1 人 员 信 息 类 图 


非常 简单 ， 有 一 个 对 象 UserInfo 存 储 用 户 的 所 有 信息 (实际 系统 上 
还 有 很 多 子 类 ， 不 多 说 了 ) ， 也 就 是 BO (Business Object， 业 务 对 
象 ) ， 这 个 对 象 设计 为 贫血 对 象 (Thin Business Object) ， 不 需要 存储 
状态 以 及 相关 的 关系 ， 本 人 是 反对 使 用 充血 对 象 (Rich Business 
Object) ， 这 里 提 到 两 个 名 词 : 贫血 对 象 和 充血 对 象 ， 这 两 个 名 词 很 简 
单 ， 在 领域 模型 中 分 别 叫做 贫血 领域 模型 和 充血 领域 模型 ， 有 什么 区 
别 昵 ? 一 个 对 象 如 果 不 存储 实体 状态 以 及 对 象 之 间 的 关系 ， 该 对 象 就 
叫做 贫血 对 象 ， 对 应 的 领域 模型 就 是 贫血 领域 模型 ， 有 实体 状态 和 对 
象 关系 的 模型 就 是 充血 领域 模型 。 看 不 懂 没 关系 ， 都 是 糊弄 人 的 东 


西 ， 属 于 专用 名 词 。 扯 远 了 ， 我 们 继续 说 我 们 的 人 力 次 源 管理 项 目 ， 

这 个 UserInfo 对 象 ， 在 系统 中 很 多 地 方 使 用 ， 你 可 以 查看 自己 的 信息 ， 
也 可 以 修改 ， 当 然 这 个 对 象 是 有 setter 方 法 的 ， 我 们 这 里 用 不 到 就 隐藏 
控 了 。 先 来 看 接口 ， 员 工 信 息 接口 如 代码 消 单 19-1 所 示 。 


代码 清单 19-1 员工 信息 接口 


public interface IUSerInfo { 
// 获 得 用 户 姓名 
public String getUserName( ); 
// 获 得 家 庭 地 址 
public String getHomeAddress() ; 
// 手 机 号 码 ， 这 个 太 重 要 ， 手 机 泛滥 呀 
public String getMobileNumber(); 
// 办 公 电 话 ， 一 般 是 座机 
public String getofficeTelNumber(); 
// 这 个 人 的 职位 是 什么 
public String getJobPosition(); 
// 获 得 家 庭 电 话 ， 这 有 点 不 好 ， 我 不 喜欢 打 家 庭 电 话 讨论 工作 
public String getHomeTelNumber(); 


员工 信息 接口 有 了 ， 就 需要 设计 一 个 实现 类 来 容纳 数据 ， 如 代码 
清单 19-2 所 示 。 


代码 清单 19-2 实现 类 


public class UserInfo implements IUserInfo { 


/* 
* 获得 家 庭 地 址 ， 下 属 送 礼 也 可 以 找到 地 方 
*/ 


public String getHomeAddress() { 
System.out.println(" 这 里 是 员工 的 家 庭 地 址 ..."); 
return null; 


3 
/< 
* 获得 家 庭 电 话 号 码 


WA 
public String getHomeTelNumber() { 
System.out.println(" 员 工 的 家 庭 电 话 是 ,..")， 
return null; 


} 

的 

* 员工 的 职位 ， 是 部 门 经 理 还 是 普通 职员 
“人 


public String getJobPosition( ) { 
System.out .println(" 这 个 人 的 职位 是 BOSS..."); 
return null; 
} 
/* 
* 手机 号 码 
*/ 
public String getMobileNumber() { 
System.out.println(" 这 个 人 的 手机 号 码 是 0900..."); 
return null; 


2 

/* 

* 办 公 室 电话 ， 烦 躁 的 时 候 最 好 "不 小 心 "把 电话 线 踢 挥 
*/ 


public String getofficeTelNumber() { 
System.out.println(" 办 公 室 电话 是 ,,,"); 
return null; 


} 
A 
* 姓名 ， 这 个 很 重要 
*/ 
public String getUserName() { 
System.out.println(" 姓 名 叫做 ,,,")， 
return null; 


这 个 项 目 是 2004 年 年 压 投 产 的 ， 运 行 到 2005 年 年 抬 还 古 比 较 平稳 
的 ， 中 间 修 修补 补 也 很 正常 ，2005 年 年 的 不 知道 是 哪 股 风 吹 的 ， 很 多 
公司 开始 使 用 借 聘 人 员 的 方式 引进 人 员 ， 我 们 公司 也 不 例外 ， 从 一 个 
天 动 货源 公司 借用 了 一 大 批 的 低 技术 、 低 工资 的 人 员 ， 分 配 到 各 个 子 
， 总 共有 将 近 200 人 ， 然 后 人 力 资源 部 就 找 我 们 部 门 老大 谈判 ， 说 


公 


叫 


要 增加 一 个 功能 :借用 人 员 管 理 ， 老 大 一 看 有 钱 赚 呀 ， 一 折 大 腿 ， 
做 ! 


老大 命令 一 下 来 ， 我 立马 带 人 过 去 调研 ， 需 求 就 一 句 话 ， 但 是 真 
深入 地 调研 还 真 不 是 那么 简单 。 借 聘 人 员 虽 然 在 我 们 公司 干 活 ， 和 我 
们 一 个 样 ， 干 话 时 没有 任何 的 差别 ， 但 是 他 们 的 人 员 人 信息、 工资 情 
况 、 福 利 情况 等 都 是 由 劳动 服务 公司 管理 的 ， 并 且 有 一 套 目 己 的 人 员 
管理 系统 ， 人 力 资 源 部 门 束 要 求 我 们 系统 同步 劳动 服务 公司 的 信息 ， 
当然 是 只 要 在 我 们 公司 工作 的 人 员 信 息 ， 其 他 人 员 信 息 是 不 需要 的 ， 
而 且 还 有 要求 信息 同步 ， 也 了 束 是 : 劳动 服务 公司 的 人 员 信 息 一 变更 ， 我 
们 系统 就 应 该 立刻 体现 出 来 ， 为 什么 要 即时 而 不 批量 昵 ? 是 因为 我 们 
公司 与 万 动 服务 公司 之 间 旦 按照 人 头 收费 的 ， 示 管 是 什么 人 ， 只 要 我 
们 公司 借用 ， 就 这 个 价格 ， 我 要 一 个 人 研究生， 你 派 了 一 个 高 中 生 给 
我 ， 那 算 什么 事 ? 因此 ， 了 解 了 业务 需求 用 后 ， 项 目 组 决定 采用 RMI 

(Remote Method Invocation， 远 程 对 象 调用 ) 的 方式 进行 联机 交互 ， 
但 是 深入 分 析 后 ， 一 个 重大 问题 立刻 显现 出 来 :劳动 服 务 公 司 的 人 员 
对 象 和 我 们 系统 的 对 象 不 相同 ， 他 们 的 对 象 如 下 所 示 。 


<<Interface>> 
IOuterUser 


+Map getUSeTBaseJnto() 


+Map getUserOtficeInfo() 
+Map getUserHomelInto() 


4 
-于 
图 19-2 劳动 服务 公司 的 人 员 信 息 类 图 


劳动 服务 公司 是 把 人 员 信 息 分 为 了 三 部 分 ， 基 本 信息 、 办 公信 息 
和 个 人 家 庭 信息 ， 并 且 都 放 到 了 HashMap 中 ， 比 如 人 员 的 姓名 放 到 
BaseInfo 信 息 中 ， 家 庭 地 址 放 到 HomeInfo 中 ， 这 也 是 一 个 可 以 接受 的 模 
式 ， 我 们 来 看 看 他 们 的 代码 ， 接 口 如 代码 清单 19-3 所 示 。 


代码 清单 19-3 劳动 服务 公司 的 人 员 信 息 接 口 


public interface IOuterUser { 
// 基 本 信息 ， 比 如 名 称 、 性 别 、 手 机 号 码 等 
public Map getUserBaseInfo(); 
// 工 作 区 域 信息 


public Map getUserofficeInfo(); 
// 用 户 的 家 庭 信 息 
public Map getUserHomeInfo( ); 


玫 动 服务 公司 的 人 员 信 息 是 这 样 存放 的 ， 如 代码 清单 19-4 所 示 。 


代码 清单 19-4 劳动 服务 公司 的 人 员 实 现 


public class OuterUser implements IOuterUser { 
yA 
* 用 户 的 基本 信息 
*/ 
public Map getUserBaseInfo() { 
HashMap baseInfoMap = new He 
baseInfoMap .put("userName"， "这 个 员工 叫 混 世 魔 王 .. 
i eh et a "这 个 员工 电话 是 ，. 
return baseInfoMap; 


} 
/* 
员工 的 家 庭 信 息 
*/ 
public Map getUserHomeInfo() { 
HashMap homeInfo = new HashMap( ); 
homeInfo.,put("homeTelNumbner"， "员工 的 家 庭 电 话 是 ，. 


." ); 


es 


homeInfo,put("homeAddress",， "员工 的 家 庭 地 址 是 ，. "); 


return homeInfo; 


3 

yA 

* 员工 的 工作 信息 ， 比 如 ， 职 位 等 
WA 


public Map getUserOofficeInfo() { 
HashMap officeInfo = new HashMap( ); 
officeInfo.put("jobPosition", "这 个 人 的 职位 是 


BOSS..."); 
officeInfo.put("officeTelNumber"， "员工 的 办 公 电 话 
是 ， ") 
return officeInfo; 
} 


了 


看 到 这 里 ， 咱 不 好 说 他 们 系统 设计 得 不 好 ， 问 题 是 咱 的 系统 要 和 
他 们 的 系统 进行 交互 ， 霞 么 办 ? 我 们 不 可 能 为 了 这 一 小 小 的 功能 而 对 
我 们 已 经 运行 良好 系统 进行 大 手术 ， 那 怎么 办 ? 我 们 可 以 转化 ， 先 拿 
到 对 方 的 数据 对 象 ， 然 后 转化 为 我 们 自己 的 数据 对 象 ， 中 间 加 一 层 转 
换 处 理 ， 按 照 这 个 思路 ， 我 们 设计 了 如 图 19-3 所 示 的 类 图 。 


<<Interface>> 
IUserInfo 
| 
+String getUserName()() 
+String getHomeAddress() 
+String get Mobile Number() 


+Strng getOfficeTeINumber() 


<<Interface>> 
IOuterUser 
| 


+Map getUserBaselInfo() 


+Map getUserOfficeInfo() 
+Map getUserHomelInfo() 


+String getJobP osition() 
+String getHome TeINumber() 


OuterUserlnfo ~ OuterUser 
| 一 一 一 一 | 
== SQ 


图 19-3 增加 了 中 转 处 理 的 人 员 信 息 类 图 


大 家 可 能 会 问 ， 这 两 个 对 象 都 不 在 一 个 系统 中 ， 你 如 何 使 用 呢 ? 
简单 ! RMI 已 经 帮 我 们 做 了 这 件 事情 ， 只 要 有 接口 ， 就 可 以 把 远程 的 
对 象 当 成 本 地 的 对 象 使 用 ， 这 个 大 家 有 时间 可 以 去 看 一 下 RMI 广 档 ， 
不 多 说 了 。OuterUserInfo 可 以 看 做 是 “两 面 派 ”， 实 现 了 IUserInfo 接 口 ， 
还 继承 了 OuterUser， 通 过 这 样 的 设计 ， 把 OuterUser 仿 闻 成 我 们 系统 


一 个 IUserInfo 对 象 ， 这 样 ， 我 们 的 系统 基本 不 用 修改 ， 所 有 的 人 员 查 
询 、 调 用 跟 本 地 一 样 。 


注意 ”我们 之 所 以 能 够 增加 一 个 OuterUserInfo 中 转 类 ， 是 因为 我 
们 在 系统 设计 时 严格 遵守 了 依赖 倒置 原则 和 里 氏 蔡 换 原 则 ， 否 则 即使 
增加 了 中 转 类 也 无 法 解决 问题 。 


吨 


说 得 口 干 舌 燥 ， 下 边 我 们 来 看 具体 的 代码 实现 ， 中 转角 色 
OuterUserInfo 如 代码 清单 19-5 所 示 。 
代码 清单 19-5 中 转角 色 


public class OuterUserInfo extends OuterUser implements 
IUSerInfo { 


private Map baseInfo = super.getUserBaseInfo(); // 员 工 的 基本 


4 


A 
口 ,DY 


private Map homeInfo = super.getUserHomeInfo(); // 员 工 的 家 庭 


A 
叫 DY 


private Map officeInfo = super.getUserOfficeInfo()，V// 工 作 信 


E 


Es 


/* 
* 家 庭 地 址 
*/ 
public String getHomeAddress() { 
String homeAddress = 
(String)this.homeInfo.get("homeAddress"); 
System.out.printiln(homeAddress); 
return homeAddress,; 
} 
7X* 
* 家 庭 电 话 号 码 
*/ 
public String getHomeTelNumber() { 
String homeTelNumber = 
(String)this.homeInfo.get("homeTelNumber"); 


System.out.println(homeTeJINumber ) ; 
return homeTelNumber; 
} 
/* 
* 职 位 信息 
yh 
public String getJobPosition() { 
String jobPosition = 
(String)this.officeInfo.get("jobPposition"); 
System.out.println(jobPosition); 
return jobPosition; 


} 


7 去 
* 手机 号 码 
*/ 


public String getMobileNumber() { 
String mobileNumber = 
(String)this.baseInfo.get("mobileNumber"); 
System.out.println(mobileNumber ); 
return mobileNumber; 
} 
/A 
* 办 公 电 话 
4 
public String getOofficeTelNumber() { 
String officeTelNumber = 
(String)this.officeInfo.get("officeTelNumber"); 
System.out.println(officeTelNumber ); 
return officeTelNumber,; 


} 

/J* 

* 员工 的 名 称 
*/ 


public String getUserName() { 
String userName = 
(String)this.baseInfo.get("userName"); 
System.out.println(userName); 
return userName; 


大 家 看 到 没 ? 中 较 的 角色 有 很 多 的 强制 类 型 较 换 ， 束 是 (String) 这 
个 东西 ， 如 果 使 用 泛 型 的 话 ， 就 可 以 完全 避免 这 个 转化 (当然 了 ， 泛 
型 当时 还 没有 诞生 ) 。 我 们 要 看 看 这 个 中 转 是 否 真 的 起 到 了 中 转 的 作 


用 ， 我 们 想象 这 样 一 个 场景 : 公司 大 老板 想 看 看 我 们 自己 公司 年 轻 女 
孩子 的 电话 号 码 ， 那 该 场景 类 束 如 代码 清单 19-6 所 示 。 


代码 清单 19-6 场景 类 


public class Client { 
public static void main(String[] args) { 
// 没 有 与 外 系统 连接 的 时 候 ， 是 这 样 写 的 
IUserIinfo youngGirl = new UserInfo(); 
// 从 数据 库 中 查 到 101 个 
for(int i=0;i<101;i++)t{ 
youngGirl.getMobileNumber(); 
} 


这 老板 比较 色 呀 。 从 数据 库 中 生成 了 101 个 UserInfo 对 象 ， 直 接 打 
印 出 来 就 成 了 。 老 板 回 头 一 想 ， 不 对 呀 ， 锡 子 不 吃 窜 边 草 ， 还 是 调 取 
借用 人 员 看 看 ， 于 是 要 查询 出 借用 人 员 中 美女 的 电话 号 码 ， 如 代码 清 
单 19-7 所 示 。 


代码 清单 19-7 查看 劳动 服务 公司 人 员 信 息 场 景 


public class Client { 
public static void main(String[] args) { 
// 老 板 一 想 不 对 呀 ， 锡 子 不 吃 窝 边 草 ， 还 是 找 借用 人 员 好 后 
// 我 们 只 修改 了 这 人 句 话 
IUserIinfo youngGirl = new OuterUserInfo(); 
// 从 数据 库 中 查 到 101 个 
for(int i=0;i<101;i++){ 
youngGirl.getMobileNumber(); 
} 


大 家 看 ， 使 用 了 适配器 模式 只 修改 了 一 句 话 ， 其 他 的 业务 逻辑 都 
不 用 修改 就 解决 了 系统 对 接 的 问题 ， 而 且 在 我 们 实际 系统 中 只 是 增加 
了 一 个 业务 类 的 继承 ， 束 实现 了 可 以 碍 本 公司 的 员工 信息 ， 也 可 以 人 硬 
人 力 资 源 公司 的 员工 信息 ， 尽 量 少 的 修改 ， 通 过 扩展 的 方式 解决 了 该 


问题 。 这 就 古 运 配 模 式 。 


[1] 出 上 自 《 史 记 - 卷 九 十 二 》。 


19.2 适 配 希 模式 的 定义 


适配器 模式 (Adapter Pattern) 的 定义 如 下 : 


Convert the interface of a class into another interface clients 
expect.Adapter lets classes work together that couldn't otherwise because of 
incompatible interfaces. (将 一 个 类 的 接口 变换 成 客户 端 所 期 符 的 另 一 种 
接口 ， 从 而 使 原本 因 接 口 不 匹配 而 无 法 在 一 起 工作 的 两 个 类 能 够 在 一 
起 工作 。) 


适配器 模式 又 叫做 变压器 模式 ， 也 叫做 包装 模式 (Wrapper) ， 但 
是 包装 模式 可 不 止 一 个 ， 还 包括 了 第 17 章 讲解 的 装饰 模式 。 适 配器 模 
式 的 通用 类 图 ， 如 图 19-4 所 示 。 


二 Request() 


= 二 = 
+SpecificRequest() 


图 19-4 适 配 胡 模 式 通用 类 图 


适 配 姻 模式 在 生活 中 还 是 很 常见 的 ， 比 如 你 笔记 本 上 的 电源 适 配 
强 ， 可 以 使 用 在 110~~220V 之 间 变 化 的 电源 ， 而 笔记 本 还 能 正常 工作 ， 
这 也 是 适 配 絮 一 个 民 好 模式 的 体现 ， 简 单 地 说 ， 适 配 帮 模式 束 古 把 一 
个 接口 或 类 转换 成 其 他 的 接口 或 类 ， 从 男 一 方面 来 说 ， 适 配 如 模式 也 
束 是 一 个 包 冯 模式， 为 什么 呢 ? 它 把 Adaptee 包 汤 成 一 个 Target 接 口 的 
类 ， 加 了 一 层 衣 服 ， 包 小 成 男 外 一 个 靓 妞 了 。 大 家 知道 ， 设 计 模 式 原 
是 为 建筑 设计 而 服务 的 ， 软 件 设计 模式 只 是 借用 了 人 家 的 原理 而 已 ， 
那 我 们 来 看 看 最 原始 的 适 配 右 古 如 何 设计 的 ， 如 图 19-5 所 示 。 


A、B 两 个 图 框 代 表 已 经 塑 模 成 型 的 物体 A 和 物体 B， 那 现在 要 求 把 
A 和 B 安 装 在 一 起 使 用 ， 如 何 安 装 ? 两 者 的 接口 不 一 致 ， 是 不 可 能 安装 
在 一 起 使 用 的 ， 那 怎么 办 ? 引入 一 个 物体 C， 如 图 19-6 所 示 。 


wi | ee 


图 19-5 两 个 已 经 成 型 的 物体 
图 19-6 引入 物体 C 


引入 物体 C 后 ，C 适 应 了 物体 A 的 接口 ， 同 时 也 适应 了 物体 B 的 接 
口 ， 然 后 三 着 束 可 以 组 合成 一 个 完整 的 物体 ， 如 图 19-7 所 示 。 


图 19-7 完美 组 合 
其 中 的 物体 C 就 是 我 们 说 的 适配器 ， 它 在 中 间 起 到 了 角色 转换 的 作 
用 ， 把 原 有 的 长 条 形 接口 转换 了 三 角形 接口 。 在 我 们 软件 业 的 设计 模 
式 中 ， 适 配器 模式 也 是 相似 的 功能 ， 那 我 们 先 来 看 看 适配器 模式 的 二 
个 角色 。 


e Target 目 标 角 色 


该 角色 定义 把 其 他 类 转换 为 何 种 接口 ， 也 就 是 我 们 的 期 户 接 口 ， 
例子 中 的 TUserInfo 接 口 束 是 目标 角色 。 


e Adaptee 源 角色 


你 想 把 谁 转换 成 目标 角色 ， 这 个 “ 谁 ” 束 是 源 角 色 ， 它 古 已 经 存在 
的 、 运 行 民 好 的 类 或 对 象 ， 经 过 适配器 角色 的 包装 ， 它 会 成 为 一 个 内 
新 、 靓 丽 的 角色 。 


e Adapter 适 配 姨 角色 


适 配 融 模式 的 核心 角色 ， 其 他 两 个 角色 都 古 已 经 存在 的 角色 ， 而 
适 配 右 角色 是 需要 新 建立 的 ， 它 的 职责 非常 简单 ， 把 源 角色 转换 为 目 
标 角 色 ， 怎 么 转换 ? 通过 继承 或 是 类 关联 的 方式 。 


各 个 角色 的 职 贡 者 已 经 非 党 清楚， 我们 再 来 看 看 其 通用 源码 ， 目 
标 接 口 如 代码 清单 19-8 所 示 。 


代码 清单 19-8 目标 角色 


public interface Target { 
// 目 标 角色 有 自己 的 方法 
public void request(); 


目标 角色 是 一 个 已 经 在 正式 运行 的 角色 ， 你 不 可 能 去 修改 角色 中 
的 方法 ， 你 能 做 的 就 是 如 何 去 实 现 接口 中 的 方法 ， 而 且 通 常情 况 下 ， 
目标 角色 是 一 个 接口 或 者 是 抽象 类 ， 一 般 不 会 是 实现 类 。 一 个 正在 服 
役 的 目标 角色 ， 如 代码 清单 19-9 所 示 。 


代码 清单 19-9 目标 角色 的 实现 类 


public class ConcreteTarget implements Target { 
public void request() { 
System.out.println("if you need any help,pls call 
me!l"); } 


源 角 色 也 是 已 经 在 服役 状态 (当然 ， 非 要 新 建立 一 个 源 角 色 ， 然 
后 套用 适配器 模式 ， 那 也 没有 任何 问题 ) ， 它 是 一 个 正常 的 类 ， 其 源 
代码 如 代码 清单 19-10 所 示 。 


代码 清单 19-10 源 角色 


public class Adaptee { 
// 原 有 的 业务 逻辑 
public void doSomething( ){ 
System.out.printJln("I'm kind of busy,1leave me 
alone, pls!"); 


> 


我 们 的 核心 角色 要 出 场 了 ， 适 配 占 角色 如 代码 清单 19-11 所 示 。 


代码 清单 19-11 适配器 角色 


public class Adapter extends Adaptee implements Target { 
public void request() { 
Super .doSomething( ); 


所 有 的 角色 部 已 经 在 场 了 ， 那 我 们 整 开始 看 看 这 


文 场 演出 ， 场 景 : 
如 代码 清单 19-12 所 示 。 


代码 清单 19-12 场景 


public class Client { 
public static void main(String[] args) { 


// 原 有 的 业务 逻辑 

Target target = new ConcreteTarget(); 
target.request(); 

// 现 在 增加 了 适配器 角色 后 的 业务 逻辑 

Target target2 = new Adapter(); 
target2.request(); 


适 配 妖 模式 的 原理 就 讲 这 么 多 吧 ， 但 是 别 得 意 得 太 早 了 ， 如 果 你 
认为 适 配 套 模式 殉 这 么 简单 ， 那 我 告诉 你 ， 你 错 了 ! 复杂 的 还 在 后 
面 。 


19.3 适 配 硕 模式 的 应 用 
19.3.1 适 配 妖 模式 的 优点 

e 适配器 模式 可 以 让 两 个 没有 任何 关系 的 类 在 一 起 运行 ， 只 要 适 
配 絮 这 个 角色 能 够 搞定 他 们 就 成 。 

e 增加 了 类 的 透明 性 


想 想 看 ， 我 们 访问 的 Target 目 标 角色 ， 但 是 具体 的 实现 都 委托 给 了 
源 角色 ， 而 这 些 对 高 层次 模块 是 透明 的 ， 也 是 它 不 需要 关心 的 。 


e 提高 了 类 的 复 用 度 


当然 了 ， 源 角色 在 原 有 的 系统 中 还 是 可 以 正常 使 用 ， 而 在 目标 和 角 
色 中 也 可 以 充当 新 的 演员 。 


e 灵活 性 非常 好 


某 一 天 ， 突 然 不 想 要 适配器 ， 没 问题 ， 删 除 掉 这 个 适 配 右 就 可 以 
了 ， 其 他 的 代码 都 不 用 修改 ， 基 本 上 束 类 似 一 个 灵活 的 构件 ， 想 用 束 
用 ,不 想 束 好 载 。 


19.3.2 适 配 希 模式 的 使 用 场景 


适 配 絮 应 用 的 场景 只 要 记 住 一 点 束 足 够 了 : 你 有 动机 修改 一 个 已 
经 投产 中 的 接口 时 ， 适 配 絮 模式 可 能 是 最 适合 你 的 模式 。 比 如 系统 扩 
展 了 ， 需 要 使 用 一 个 已 有 或 新 建立 的 类 ， 但 这 个 类 又 不 符合 系统 的 接 
口 ， 怎 么 办 ? 使 用 适 配 右 模式 ， 这 也 是 我 们 例子 中 提 到 的 。 


19.3.3 适配器 模式 的 注意 事项 


适 配 事 模式 最 好 在 详细 设计 阶段 不 要 考虑 它 ， 它 不 是 为 了 解决 还 
处 在 开发 阶段 的 问题 ， 而 是 解决 正在 服役 的 项 目 问 题 ， 没 有 一 个 系统 
分 析 师 会 在 做 详细 设计 的 时 候 堵 虑 使 用 适 配 右 模式 ， 这 个 模式 使 用 的 
主要 场景 是 扩展 应 用 中 ， 殉 像 我 们 上 面 的 那个 例子 一 样 ， 系 统 扩 展 
了 ,不 符合 原 有 设计 的 时 候 才 考虑 通过 适配器 模式 减少 代码 修改 市 来 
的 风险 。 


再 次 提醒 一 点 ， 项 目 一 定 要 遵守 依赖 倒置 原则 和 里 氏 礁 换 原则 ， 
否则 即使 在 适合 使 用 适 配 右 的 场合 下 ， 也 会 市 来 非常 大 的 改造 。 


19.4 适 配 硕 模式 的 扩展 


我 们 刚刚 讲 的 人 力 资 源 管理 的 例子 中 ， 其 实 古 一 个 比较 六 运 的 例 
子 ， 为 什么 呢 ? 如 果 劳 动 服务 公司 提供 的 人 员 接 口 不 止 一 个 ， 也 就 是 
说 ， 用 户 基 本 信息 是 一 个 接口 ， 工 作 信 息 是 一 个 接口 ， 家 庭 信 息 是 一 
个 接口 ， 总 共有 三 个 接口 三 个 实现 类 ， 想 想 看 如 何 处 理 呢 ?不 能 再 使 
用 我 们 上 面 的 方法 了 ， 为 什么 呢 ? Java 是 不 文 持 多 继承 的 ， 你 难道 想 让 
OuterUserInfo 继 承 三 个 实现 类 ? 此 路 不 通 ， 再 想 一 个 办 法 ， 对 哦 ， 可 以 
使 用 类 关联 的 办 法 嘛 ! 声明 一 个 OuterUserInfo 实 现 类 ， 实 现 IUserImnfo 接 
口 ， 通 过 再 关联 其 他 三 个 实现 类 不 就 可 以 解决 这 个 问题 了 吗 ? 是 的 ， 
是 的 ， 好 方法 ， 我 们 先 画 出 类 图 ， 如 图 19-8 所 示 。 


OuterUserInfo 通 过 关联 的 方式 与 外 稻 的 三 个 实现 类 通讯 ， 当 然 也 可 
以 理解 为 是 聚合 关系 。IUserInfo 和 UserInfo 代 码 如 代码 清单 19-1 和 代码 
清单 19-2 所 示 ， 不 再 费 述 。 我 们 来 看 看 拆 分 后 的 三 个 接口 和 实现 类 ， 用 
户 基本 信息 接口 如 代码 清单 19-13 所 示 。 


<<Interface>> 
IJOuterUserBaseInfo 


<<interface>> 
IUserInfo 
EE 
+Strng getUserName()() 
+Strng getHomeAddress() 
tStrng getMobile Number() 
+String getOfficeTeINumber() 


tString getJobPosition() OuterUserBaselnfo 


+String gctHome TelINumber() 


+Map getUserBaseInfo() 


<<interface>> 
IOQuterUserHomeInfo 


UserInfo OuterUserinfo 


Eee 
HMap getUserHomeJInfo0) 


OuterUserHome Info 


<<interface>> 
IOQOuterOfficeInfo 


+Map getUserOfficeInfo() 


OuterUserOfficeInfo 


图 19-8 拆 分 接口 后 的 类 图 


代码 清单 19-13 用 户 基本 信息 接口 


public interface IOuterUserBaseInfo { 
// 基 本 信息 ， 比 如 名 称 、 性 别 、 手 机 号 码 等 
public Map getUserBaseInfo( ) ; 


Le 


用 户 家 庭 信 息 接 口 如 代码 清单 19-14 所 示 


代码 清单 19-14 用 户 家 庭 信 息 接 口 


public interface IOuterUserHomeInfo { 
// 用 户 的 家 庭 信息 
public Map getUserHomeInfo( ) ， 


O 


用 户 工 作 信息 接口 如 代码 清单 19-15 所 示 


代码 清单 19-15 用 户 工作 信息 接口 


public interface IOuterUserofficeInfo { 
// 工 作 区 域 信息 
public Map getUserofficeInfo( ) ， 


读 a 到 这 里 ， 读 考 应 该 想到 这 样 一 个 问题 ， 系 统 这 样 设计 是 否 合理 
呢 ? 合理 ， 绝 对 合理 ! 想 想 单一 职责 原则 是 怎么 说 的 ， 类 和 接口 要 保 
持 职责 单一 ， 在 实际 的 应 用 中 类 可 以 有 多 重 职责 ， 但 是 接口 一 定 要 职 

， 因 此 ， 我 们 上 面 拆 分 接口 的 假想 也 是 非常 合乎 逻 措 的 。 我 们 
来 看 三 个 相关 的 实现 类 ， 用 户 基 本 信息 如 代码 清单 19-16 所 示 。 


代码 清单 19-16 用 户 基 本 信息 
public class OuterUserBaseInfo implements IOuterUserBaseInfo { 
A 


* 用 户 的 基本 信息 
A 
public Map getUserBaseInfo() { 
HashMap baseInfoMap = new HashMap( 
baseInfoMap.put("userName", "这 个 员工 叫 混 世 魔王 ..."); 
eS ae "这 个 员工 电话 是 ...")，; 
return baseInfoMap; 


用 户 家 庭 信 息 如 代码 清单 19-17 所 示 。 


代码 清单 19-17 用 户 家 庭 信息 


public class OuterUserHomeInfo implements IOuterUserHomeInfo { 
/* 


* 员工 的 家 庭 信息 
*/ 
public Map getUserHomeInfo() { 
HashMap homeInfo = new HashMap( ); 
homeInfo.put("homeTelNumbner",， "员工 的 家 庭 电 话 是 ,.."); 
homeInfo,put("homeAddress",， "员工 的 家 庭 地 址 是 ,,."); 
return homeInfo; 


用 户 工 作 信息 如 代码 清单 19-18 所 示 。 


代码 清单 19-18 用 户 工作 信息 


public class OuterUserofficeInfo implements IOuterUserofficeInfo 


{ 


* 员工 的 工作 信息 ， 比 如 ， 职 位 等 
public Map getUserOofficeInfo() { 
HashMap officeInfo = new HashMap(); 
officeInfo.put("jobPosition", "这 个 人 的 职位 是 


BOSS..."); 
officeInfo.put("officeTelNumber"， "员工 的 办 公 电 话 
是 ， ") 
return officeInfo; 
} 
} 


这 里 又 到 我 们 的 核心 了 一 一 适配器 。 好 ， 我 们 来 看 适配器 代码 ， 
如 代码 清单 19-19 所 示 。 


代码 清单 19-19 适配器 


public class OuterUserInfo implements IUSserInfo { 


// 源 目标 对 象 


private IOuterUserBaseInfo baseInfo = null; // 员 工 的 基本 
信 已 

private IOuterUserHomeInfo homeInfo = null,; // 员 工 的 家 庭 
信 息 


private IOuterUser0fficeInfo officeInfo = null; // 工 作 信 息 

// 数 据 处 理 

private Map baseMap = null; 

private Map homeMap = null; 

private Map officeMap = null; 

// 构 造 函 数 传 递 对 象 

public OuteruUserInfo(IOuterUserBaseInfo 
_baseInfo, IOuterUserHomeInfo _homeInfo,IOuterUserofficeInfo 
_officeInfo){ 


this.baseInfo = _baseInfo; 
this.homeInfo = _homeInfo; 
this.officeInfo = _officeInfo; 


// 数 据 处 理 

this.baseMap = this,baseInfo.getUserBaseInfo( ) ; 

this.homeMap = this,homeInfo.getUserHomeInfo( ) ; 

this.officeMap = 
this.officeInfo.getUserofficeInfo( ); 


} 
// 家 庭 地 址 
public String getHomeAddress() { 
String homeAddress = 
(String)this.homeMap.get("homeAddress"); 
System.out.println(homeAddress); 
return homeAddress; 


// 家 庭 电 话 号 码 
public String getHomeTelNumber() { 
String homeTelNumber = 
(String)this.homeMap.get("homeTelNumber"); 
System.out.printJln(homeTeJINumber ) ; 
return homeTelNumber; 


} 
// 职 位 信息 
public String getJobPosition() { 
String jobPosition = 
(String)this.officeMap.get("jobPosition"); 
System.out.println(jobPosition); 
return jobPosition; 


} 
// 手 机 号 码 
public String getMobileNumber() { 
String mobileNumber = 
(String)this.baseMap.get("mobileNumber"); 
System.out.println(mobileNumber ); 
return mobileNumber; 


} 
// 办 公 电 话 
public String getofficeTelNumber() { 
String officeTelNumber= 
(String)this.officeMap.get("officeTelNumber"); 
System.out.println(officeTelNumber ); 
return officeTelNumber,; 


} 
// 员工 的 名 称 
public String getUserName() { 
String userName = 
(String)this.baseMap.get("userName"); 
System.out.println(userName); 
return userName; 


大 家 只 要 注意 一 下 黑色 字体 的 构造 函数 就 可 以 了 ， 它 接收 三 个 对 
象 ， 其 他 部 分 变化 不 大 ， 只 是 变量 名 称 进行 了 修改 ， 我 们 再 来 看 场景 
类 ， 如 代码 清单 19-20 所 示 。 


代码 清单 19-20 场景 类 


public class Client { 
public static void main(String[] args) { 

// 外 系统 的 人 员 信 息 

IOuterUserBaseInfo baseInfo = new 
OuterUserBaseInfo( ) ; 

IOuterUserHomeInfo homeInfo = new 
OuterUserHomeInfo( ); 

IOuterUserofficeInfo officeInfo = new 
OuterUserofficeInfo( ); 

// 传 递 三 个 对 象 

IUSerInfo youngGirl = new 

OuterUserIinfo(baseInfo,homeInfo,officeInfo); 


// 从 数据 库 中 查 到 101 个 

for(int i=0;i<101;i++){ 
youngGirl.getMobileNumber(); 

} 


运行 的 结果 还 是 相同 的 。 大 家 想 想 看 ，OuterUserInfo 变 成 了 委托 服 
务 ， 把 IUserInfo 接 口 需要 的 所 有 的 操作 都 委托 给 其 他 三 个 接口 下 的 实 
现 类 ， 它 的 委托 是 通过 对 象 层次 的 关联 关系 进行 委托 的 ， 而 不 是 继承 
关系 。 好 了 ， 讲 了 这 么 多 ， 我 们 需要 给 这 种 适配器 起 个 名 字 ， 台 是 对 
象 适配器 ， 我 们 之 前 讲 的 通过 继承 进行 的 适 配 ， 叫 做 类 适配器 。 对 象 
适配器 的 通用 类 图 ， 如 图 19-9 所 示 。 
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+Request() 


Client 


Adaptee2 
Adapteel Adapter 
一 一 EE hs 
+SpecificRequest() Ee +SpeciticRequestO) 


图 19-9 对 象 适 配器 类 图 


适 配 硼 的 通用 代码 也 比较 简单 ， 把 原 有 的 继承 关系 变更 为 天 联 天 
系 束 可 以 了 ， 不 再 资 述 。 对 象 适配器 和 类 适配器 的 区 别 是 ， 类 适 配 妖 
征 类 间 继 承 ， 对 和 象 适配器 是 对 象 的 合成 关系 ， 也 可 以 说 是 类 的 关联 关 


系 ， 这 是 两 者 的 根本 区 别 。 二 者 在 实际 项 目 中 都 会 经 常用 到 ， 由 于 对 
象 适配器 是 通过 类 间 的 关联 关系 进行 耦合 的 ， 因 此 在 设计 时 就 可 以 做 
到 比较 灵活 ， 比 如 修补 源 角 色 的 隐形 缺 隐 ， 关 联 其 他 对 象 等 ， 而 类 适 
配器 就 只 能 通过 履 写 源 角 色 的 方法 进行 扩展 ， 在 实际 项 目 中 ， 对 象 适 
配器 使 用 到 场景 相对 较 多 。 


19.5 最 住 实 中 


适 配 闫 模式 征 一 个 补偿 模式 ， 或 者 说 是 一 个 “补救 ”模式 ， 通 常用 
来 解决 接口 不 相 容 的 问题 ， 在 百分之百 的 完 类 设计 中 是 不 可 能 使 用 到 
的 ， 什 么 是 百分之百 的 完美 设计 ?“ 千 虚 ” 而 没有 “一 失 ” 的 设计 ， 但 
古 ， 表 完美 的 设计 也 会 遇 到 “需求 ”变更 这 个 无 法 逃避 的 问题 ， 束 以 我 
们 上 面 的 人 力 资 源 管理 系统 为 例 来 说， 不 管 系统 设计 得 多 么 完美 ， 痢 
无 法 逃避 新 业务 的 发 生 ， 技 术 只 是 一 个 工具 而 已 ， 是 因为 它 推动 了 其 
他 行业 的 进步 和 发 展 而 具有 了 价值 ， 通 俗 地 说 ， 技 术 是 为 业务 服务 
的 ， 因 此 业务 在 日 新 月 异 变化 的 同时 ， 也 对 技术 提出 了 同样 的 要求 ， 
在 这 种 要 求 下 ， 束 需要 我 们 有 一 种 或 一 些 这 样 的 补救 模式 诞生 ， 使 用 
这 些 补救 模式 可 以 保证 我 们 的 系统 在 生命 周期 内 能 够 稳定 、 可 靠 、 健 
壮 的 运行 ， 而 适 配 右 模式 束 是 这 样 的 一 个 “救世 主 *， 它 在 需求 巨变 、 
业务 飞速 而 导致 你 极度 郁 间 、 烦 蹊 、 裔 并 的 时 候 横 空 出 世 ， 它 通过 把 
非 本 系统 接口 的 对 象 包装 成 本 系统 可 以 接受 的 对 象 ， 从 而 简化 了 系统 
大 规模 变更 风险 的 存在 。 


第 20 章 ”迭代 需 模 式 


20.1 整理 项 目 信 息 


周 五 下 午 ， 我 正在 看 技术 网 站 ， 第 六 感官 发 觉 有 人 在 身后 ， 扭 头 
一 看 ， 老 大 站 在 背后 ， 我 赶忙 站 起 来 。 


“ 王 经 理 ， 你 找 我 ? ” 


“ 哦 ， 在 看 技术 呀 。 有 个 事情 找 你 谈 一 下 ， 你 到 我 办 公 室 来 一 
下 

到 老大 办 公 室 还 没 坐 稳 ， 老 大 就 开始 发 话 了 。 

是 这 样 ， 刚 刚 我 在 看 季报 ， 我 们 每 个 项 目的 支出 费用 都 很 高 ， 项 
目 情况 复杂 ， 人 员 情况 也 不 简单 ， 我 看 着 也 有 点 糊涂 ， 你 看 ， 这 是 我 
们 现在 还 在 开发 或 者 维护 的 103 个 项 目 ， 项 目 信息 很 乱 ， 很 多 是 两 年 前 
的 信息 ， 你 能 不 能 先 把 这 些 项 目 最 新 情况 重新 打印 一 份 给 我 ， 咱 们 好 
查 查 到 底 有 什么 问题 。* 老 大 说 。 


“这 个 好 办 ， 我 马上 去 办 ! 我 严 快 地 答复 道 。 


很 快 我 设计 了 一 个 类 图 ， 准 备 实施 ， 如 图 20-1 所 示 。 


<<Interface>> 
IProject 


+Strng getProjectInfo() 


人 


Project 


图 20-1 项 目 信 息 类 图 


简单 得 不 能 再 简单 的 类 图 ， 是 个 程序 员 都 能 实现 。 我 们 来 看 看 这 
个 简单 的 东西 ， 先 看 接口 ， 如 代码 清单 20-1 所 示 。 


代码 清单 20-1 项 目 信 息 接口 


public interface IProject { 
// 从 老板 这 里 看 到 的 就 是 项 目 信 息 
public String getPprojectInfo( ); 


定义 了 一 个 接口 ， 面 癌 接 口 编程 嘛 ， 当 然 要 定义 接口 了 ， 然 后 看 
看 实现 类 ， 如 代码 清单 20-2 所 示 。 


代码 清单 20-2 项 目 信 息 的 实现 


public class Project implements IProject { 
// 项 目 名 称 
private String name = ""; 
// 项 目 成 员 数 量 
private int num = 0; 


// 项 目 费 用 
private int cost = 0; 
// 定 义 一 个 构造 画 数 ， 把 所 有 老板 需要 看 到 的 信息 存储 起 来 
public Project(String namey int num,int cost)t{ 
// 赋 值 到 类 的 成 员 变 量 
this.name = name; 
this.num = num; 
this.cost=cost,; 


// 得 到 项 目的 信息 
public String getProjectInfo() { 
String info = ""; 
// 获 得 项 目的 名 称 
info = info+ "项 目 名 称 是 : " + this.name 
// 获 得 项 目 人 数 
info = info + "Nt 项 目 人 数 : "+ this.num; 
// 项 目 费 用 
info = info+ "Nt 项 目 费 用 : "+ this,cost， 
return info; 


实现 类 也 是 极度 简单 ， 通 过 构造 画 数 把 要 显示 的 数据 传递 过 来 ， 
然后 放 到 getProjectInfo 中 显示 ， 这 太 容 易 了 ! 然后 我 们 老大 要 看 看 结果 
了 ， 如 代码 清单 20-3 所 示 。 


代码 清单 20-3 老大 看 报表 的 场景 


public class Boss { 
public static void main(String[] args) { 
// 定 义 一 个 List， 存 放 所 有 的 项 目 对 象 
ArrayList<IProject> projectList = new 
ArrayList<IProject>(); 
// 增 加 星球 大 战 项 目 
projectList.add(new Project(" 星 球 大 战 项 


有 i",10,100000)); 


// 增 加 扭转 时 空 项 目 
projectList.add(new Project(" 扭 转 时 空 项 


目 ", 100 ,10000000) ); 


// 增 加 超人 改造 项 目 
projectList.add(new Project(" 超 人 改造 项 
有 ",10000, 1000000000)); 


// 这 边 100 个 项 目 
for(int i=4;i<104;i++){ 
projectList.add(new 
Project(" 第 "+i+" 个 项 目 ", i*5,i*1000000)); 


} 
// 遍 历 一 下 ArrayList， 把 所 有 的 数据 都 取出 
for(IProject project:projectList)t{ 
System.out.println(project.getProjectInfo( )); 
} 


3 


然后 看 一 下 我 们 的 运行 结 来 ， 如 下 所 示 : 


项 目 名 称 是 : 星球 大 战 项 目 项 目 人 数 : 10 项 目 费 用 : 100000 
项 目 名 称 是 : 扭转 时 空 项 目 项 目 人 数 : 100 项 目 费 用 : 10000000 
项 目 名 称 是 ， 超人 改造 项 目 项 目 人 数 : 10000 项 目 费 用 : 1000000000 
项 目 名 称 是 ， 第 4 个 项 目 项 目 人 数 : 20 项 目 费 用 : 4000000 
项 目 名称 是 : 第 5 个 项 目 项 目 人 数 : 25 项 目 费 用 : 5000000 


老大 一 看 ， 非 党 开心 ， 这 么 快 束 出 结 有 末了 ， 大 大 地 把 我 僵 奖 了 
番 ， 然 后 就 去 埋头 人 研究 那 堆 枯 炬 的 报表 了 。 我 回 到 座位 上 ， 叉 看 了 一 
遍 程序 (心里 很 乐 ， 就 又 想 看 看 自己 的 成 果 ) ， 想 想 (一 日 三 省 
嘛 ) ， 应 该 还 有 男 外 一 种 实现 方式 ， 因 为 是 遍历 嘛 ， 让 我 想到 的 就 是 
Java 的 迭代 器 接口 java.util.iterator， 它 的 作用 就 是 所 历 Collection 集 合 下 


的 元 素 ， 那 我 们 的 程序 还 可 以 有 另外 一 种 实现 ， 通 过 实现 iterator 接 口 
来 实现 遍历 ， 先 修正 一 下 类 图 ， 如 图 20-2 所 示 。 


java.util.Iterator 
PE 


+boolean hasNext() 
+E next() 


- +Vold remove() 
<<interface>> 
IProject 


+String getProjectInfo() 
+void add() 
+IProjectIterator iterator() 


| 


图 20-2 增加 送 代 接口 的 类 疼 


IProjectlterator 


Projectlterator 


看 着 是 不 是 复杂 了 很 多 ? 是 的 ， 是 有 点 复杂 了 ， 是 不 是 我 们 把 简 
单 的 事情 复杂 化 了 ? 请 读者 继续 阅读 下 去 ， 我 等 会 儿 说 明 原 因 。 我 们 
先 分 析 一 下 我 们 的 类 图 java.util.Iterator 接 口中 声明 了 三 个 方法 ， 这 是 


JDK 定 义 的 ， ProjectIterator 实现 该 接口 ， 并 且 聚 合 了 Project 对 象 ， 世 
就 是 把 Project 对 象 作 为 本 对 象 的 成 员 变 量 使 用 。 看 类 图 还 不 是 很 清晰 ， 


我 们 一 起 看 一 下 代码 ， 先 看 IProject 接 口 的 改变 ， 如 代码 清单 20-4 所 


修 ° 


代码 清单 20-4 项 目 信息 接口 


public interface IProject { 
// 增 加 项 目 
public void add(String name,int num,int cost); 
// 从 老板 这 里 看 到 的 就 是 项 目 信 息 
public String getPprojectInfo( ); 
// 获 得 一 个 可 以 被 思 历 的 对 象 


public IProjectIterator iterator(); 


ww 


这 里 多 了 两 个 方法 ， 一 个 是 add 方 法 ， 这 个 方法 是 增加 项 目 ， 也 就 
是 说 产生 了 一 个 对 象 后 ， 直 接 使 用 add 方 法 增加 项 目 信息 。 我 们 再 来 看 
其 实现 类 ， 如 代码 清单 20-5 所 示 。 


代码 清单 20-5 项 目 信 息 


public class Project implements IProject { 
// 定 义 一 个 项 目 列表 ， 所 有 的 项 目 都 放 在 这 里 
private ArrayList<IProject> projectList = new 
ArrayList<IProject>(); 
// 项 目 名 称 
private String name = ""; 
// 项 目 成 员 数 量 
private int num = 0; 
// 项 目 费 用 
private int cost = 0; 
public Project(){ 


} 
// 定 义 一 个 构造 本 数 ， 把 所 有 老板 需要 看 到 的 信息 存储 起 来 
private Project(String name,int num, Int cost){ 
// 赋 值 到 类 的 成 员 变 量 中 
this.name = name; 
this.num = num; 


this,Ccost=cost ， 


} 

// 增 加 项 目 

public void add(String name,int num,int cost)t{ 
this.projectList.add(new Project(name,num,cost)); 


} 
// 得 到 项 目的 信息 
public String getProjectInfo() { 
String info = "",， 
// 获 得 项 目的 名 称 
info = info+ "项 目 名 称 是 : " + this.name; 
// 获 得 项 目 人 数 
info = info + "Nt 项 目 人 数 : "+ this.num; 
// 项 目 费用 
info = info+ "Nt 项 目 费 用 : "+ this.cost 
return Info， 


} 
// 产 生 一 个 遍历 对 象 
public IProjectIterator iterator()t{ 
return new ProjectIiterator(this.projectList); 
} 


过 构造 函数 ， 传 递 了 一 个 项 目 所 必需 的 信息 ， 然 后 通过 iterator() 
方法 ， 把 所 有 项 目 都 返回 到 一 个 迭代 器 中 。Iterator(0) 方 法 看 不 懂 不 要 
紧 ， 继 续 辐 下 阅读 。 再 看 IProjectIterator 接 口 ， 如 代码 清单 20-6 所 示 。 


代码 清单 20-6 项 目 欠 代 硕 接 口 


public interface IProjectIterator extends Iterator { 


大 家 可 能 对 该 接口 感觉 很 奇怪 ， 你 定义 的 这 个 接口 方法 、 变 量 都 
没有 ， 有 什么 意义 呢 ? 有 意义 ， 所 有 的 Java 书 上 都 会 说 要 面向 接口 编 
程 ， 你 的 接口 是 对 一 个 事物 的 描述 ， 也 台 是 说 我 通过 接口 就 知道 这 个 
事物 有 哪些 方法 ， 哪 些 必 性， 我 们 这 里 的 IProjectIterator 是 要 建立 一 个 


指向 Project 类 的 和 迭 代 器 ， 目 前 暂时 定义 的 就 是 一 个 通用 的 迭代 器 ， 可 能 
以 后 会 增加 IProjectIterator 的 一 些 属性 或 者 方法 。 当 然 了 ， 你 也 可 以 在 
实现 类 上 实现 两 个 接口 ， 一 个 是 Iterator, 一 个 是 IProjectIterator (这 了 时 

候 ， 这 个 接口 就 不 用 继承 Iterator) ， 杀 猪 杀 尾巴 ， 各 有 各 的 杀 法 。 我 
的 习惯 是 ， 如果 我 要 实现 一 个 容器 或 者 其 他 API 提 供 接口 时 ， 我 一 般 都 
自己 先 写 一 个 接口 继承 ， 然 后 再 继承 自己 写 的 接口 ， 保 证 自己 的 实现 
类 只 用 实现 自己 写 的 接口 (接口 传递 ， 当 然 也 要 实现 顶层 的 接口 ) ， 

程序 阅读 也 清晰 一 些 。 我 们 继续 看 迭代 器 的 实现 类 ， 如 代码 清单 20-7 所 


修 ° 


代码 清单 20-7 项 目 迭 代 器 


public class ProjectIterator implements IProjectIterator { 
// 所 有 的 项 目 都 放 在 ArrayList 中 
private ArrayList<IProject> projectList = new 
ArrayList<IProject>(); 
private int currentItem = 0; 
// 构 造 函 数 传 入 projectList 
public ProjectIterator(ArrayList<IProject> projectList){ 
this.projectList = projectList 


} 

// 判 断 是 否 还 有 元 素 ， 必 须 实现 

public boolean hasNext() { 
// 定 义 一 个 返回 值 
boolean b = true; 


if(this.currentIitem>=projectList.size()||this.projectList.get(th 
is.currentIitem)==null){ 
b =false; 
} 


return b; 


} 

// 取 得 下 一 个 值 

public IProject next() { 
return 


(IProject)this.projectList.get(this.currentIitem++); 


/7 删除 一 个 对 象 
public void remove() { 


// 和 暂时 没有 使 用 到 


细心 的 读者 可 能 会 从 代码 中 发 现 一 个 问题 ，java.util.iterator 接 口中 
定义 next() 方 法 的 返回 值 类 型 是 E， 而 你 在 ProjectIterator 中 返回 值 却 是 
IProject，E 和 IProject 有 什么 关系 ? 


E 是 JDK 1.5 中 定义 的 新 类 型 : 元 素 (Element) ， 是 一 个 泛 型 符 
号 ， 表 示 一 个 类 型 ， 具 体 什 么 类 型 是 在 实现 或 运行 时 决定 ， 总 之 它 代 
表 的 是 一 种 类 型 ,你 在 这 个 实现 类 中 把 它 定 义 为 ProjectIterator， 在 为 外 
一 个 实现 类 可 以 把 它 定 义 为 String， 都 没有 问题 。 它 与 Object 这 个 类 可 
征 不 同 的 ，Object 是 所 有 类 的 父 类 ， 随 便 一 个 类 你 都 可 以 把 它 辣 上 转型 
到 Object 类 ， 也 只 是 因为 它 是 所 有 类 的 父 类 ， 它 才 有 是 一 个 通用 类 ， 而 E 
征 一 个 符号 ， 代 表 所 有 的 类 ， 当 然 也 代表 Object 了 。 


都 写 完 毕 了 ， 看 看 我 们 的 Boss 类 有 多 少 改 动 ， 如 代码 清单 20-8 所 


外 


代码 清单 20-8 老板 看 报表 


public class Boss { 
public static void main(String[] args) { 
// 定 义 一 个 List， 存 放 所 有 的 项 目 对 象 
IProject project = new Project(); 
// 增 加 星球 大 战 项 目 
project .add(" 星 球 大 战 项 目 ddddd", 19,100000); 


// 增 加 扭转 时 空 项 目 
project .add(" 招 转 时 空 项 目 
// 增 加 超人 改造 项 
project.add(" 超 人 改造 项 目 
// 这 边 100 个 项 目 


for(int i=4;i<104;i++){ 
project.add(" 第 "+i+" 个 项 


有 ",i*5,i*1000000); 


} 
// 遍 历 一 下 ArrayList, + 


所 有 的 数据 都 取出 


",100, 10000000); 


", 10000,1000000000 ); 


IProjectIterator projectIterator = 


project.iterator(); 


(IProject)projectIiterator.next(); 


IProject p = 


System.out.println(p.getProjectInfo()); 
} 


} 


运行 结果 如 下 所 示 : 


项 目 名 称 是 : 扭转 时 空 项 目 


项 目 名 称 是 : 超人 改造 项 目 


项 目 名 称 是 : 第 4 个 项 有 


项 目 名 称 是 : 第 5 个 项 目 


人 数 : 20 
人 数 : 25 


人 数 : 10 
人 数 : 100 


项 目 届 用: 


项 目 人 数 : 10000 


项 目 费 用 : 


项 上 


项 目 


济 


项 目 


3 
了 天 用: 


while(projectIiterator.hasNext())t{ 


100000 


10000000 


1000000000 


: 4000000 


: 5000000 


运行 结果 完全 相同 ， 但 是 上 面 的 程序 复杂 性 增加 了 不 少 ， 难 道 我 
们 退回 到 原始 时 代 了 吗 ? 非 也 ， 非 也 ， 只 古 我 们 回 退 到 JDK 1.0.8 版 本 
的 编程 时 代 了 ， 我 们 使 用 一 种 新 的 设计 模式 一 一 适 代 融 模式 。 


20.2 从 代 姨 模式 的 定义 


迭代 器 模式 (Iterator Pattern) 目前 已 经 是 一 个 没落 的 模式 ， 基 本 
上 没 人 会 单独 写 一 个 送 代 右 ， 除 非 是 产品 性 质 的 开发 ， 其 定义 如 下 : 


Provide a way to access the elements of an aggregate object 


sequentially without exposing its underlying representation. ( 它 提供 一 种 


方法 访问 一 个 容 需 对 象 中 各 个 元 素 ， 而 又 不 需 骏 露 该 对 象 的 内 部 细 
3 


国民 | O 〇 


迭代 吉 是 为 容 圳 服务 的 ， 那 什么 是 容器 呢 ? 能 容纳 对 象 的 所 有 类 
型 都 可 以 称 之 为 容器 ， 例 如 Collection 集 合 类 型 、Set 类 型 等 ， 迭 代 器 模 
式 就 是 为 解决 明 历 这 些 容 器 中 的 元 素 而 诞生 的 。 其 通用 类 图 ， 如 图 20-3 
所 示 。 


Tterator 


+Createlterator() 


+First() 

十 Next() 
+ISDone() 
+CurrentItem() 


Concrete Aggregate 


Concretelterator 
本 
[ss 


图 20-3 迄 代 如 模式 的 通用 类 图 
迁 代 右 模式 提供 了 所 历 容器 的 方便 性 ， 容 絮 只 要 管理 增 减 元 素 谍 
可 以 了 ， 和 需要 所 历时 交 由 和 迭代 需 进 行 。 和 迭代 妖 模式 正 是 由 于 使 用 得 太 
频 娄 ， 所 以 大 家 才 会 忽略 ， 我 们 来 看 看 欠 代 万 模式 中 的 各 个 角色 : 


e@ Iterator 抽 象 迭 代 器 


抽象 欠 代 器 负责 定义 访问 和 通 历 元 素 的 接口 ， 而 且 基 本 上 是 有 因 
定 的 3 个 方法 : first() 获 得 第 一 个 元 素 ，next() 访 问 下 一 个 元 下 ，isDone() 
是 否 已 经 访问 到 底部 (Java 叫 做 hasNext() 方 法 ) 。 


e@ Concretelterator 具 体 友 代 器 


e Aggregate 抽 和 象 容器 


容器 角色 负责 提供 创建 具体 和 迭 代 器 角色 的 接口 ， 必 然 提 供 一 个 类 
似 createlterator() 这 样 的 方法 ， 在 Java 中 一 般 是 iterator() 方 法 。 


e Concrete Aggregate 具 体 容 器 


具体 容器 实现 容器 接口 定义 的 方法 ， 创 建 出 容纳 迭代 右 的 对 象 。 


我 们 来 看 迭代 器 模式 的 通用 源 代码 ， 先 看 抽象 迭代 器 Iterator， 如 
代码 清单 20-9 所 示 。 


代码 清单 20-9 抽象 迭代 器 


public interface Iterator { 
// 遍 历 到 下 一 个 元 素 
public Object next(); 
// 是 否 已 经 忆 历 到 尾部 
public boolean hasNext(); 
// 删 除 当 前 指向 的 元 素 


public boolean remove () ; 


具体 适 代 需 如 代码 清单 20-10 所 示 。 


代码 清单 20-10 具体 迭代 器 


public class ConcreteIterator implements Iterator { 
private Vector vector = new Vector(); 
// 定 义 当 前 游标 
public int cursor = 0; 


@Suppresswarnings("unchecked") 
public ConcreteIterator(Vector _vector)t{ 


this.vector = _vector; 
} 
// 判 断 是 否 到 达 尾 音 
public boolean hasNext() { 
if(this.cursor == this.vector.size())t 
return false; 
}elsef 
return true; 
} 


} 
// 返 回 下 一 个 元 素 
public Object next() { 
Object result = null; 
if(this.hasNext())t{ 
result = this.vector.get(this,.cursor++); 


}elsef 


} 


return result,; 


} 

// 删 除 当 前 元 素 

public boolean remove() { 
this.vector.remove(this.cursor); 
return true; 


result = null; 


注意 ”开发 系统 时 ， 失 代 器 的 删除 方法 应 该 完成 两 个 逻辑 : 一 征 
删除 当前 元 素 ， 二 是 当前 游标 指 癌 下 一 个 元 聚 。 


抽象 容 右 如 代码 清单 20-11 所 示 。 


代码 清单 20-11 抽象 容器 


public interface Aggregate { 
// 是 容器 必然 有 元 素 的 增加 
public void add(Object object ) ， 
// 诚 少 元 素 


public void remove(Object object ) ; 
// 由 迭代 器 来 遍历 所 有 的 元 素 


public Iterator iterator(); 


具体 容 右 如 代码 清单 20-12 所 示 。 


代码 清单 20-12 具体 容器 


public class ConcreteAggregate implements Aggregate { 
// 容 纳 对 象 的 容器 
private Vector Vector = new Vector( ) ; 
// 增 加 一 个 元 素 
public void add(Object object) { 
this.vector.add(object); 
} 


// 返 回 迭 代 器 对 象 
public Iterator iterator() { 
return new ConcreteIterator(this.vector); 


} 

// 删 除 一 个 元 素 

public void remove(Object object) { 
this.remove(object); 

} 


场景 类 如 代码 清单 20-13 所 示 。 


代码 清单 20-13 场景 


public class Client { 
public static void main(String[] args) { 
// 声 明 出 容器 
Aggregate agg = new ConcreteAggregate( ) ; 
// 产 生 对 象 数据 放 进 去 
agg.add("abc"); 
agg.add("aaa" ); 
agg.add("1234"); 
// 裔 历 一 下 
Iterator iterator = agg.iterator(); 
while(iterator.hasNext())t{ 
System.out.println(iterator.next()); 


简单 地 说 ， 和 迭代 融 吕 类 似 于 一 个 数据 库 中 的 游标 ， 可 以 在 一 个 容 
器 内 上 下 翻 深 ， 人 遍历 所 有 它 需 要 查看 的 元 素 。 


20.3 迭 代 需 模式 的 应 用 


我 们 在 例子 中 使 用 了 迭代 器 模式 后 为 什么 使 原本 简单 的 应 用 变 得 
复杂 起 来 了 呢 ? 那 是 因为 我 们 在 简单 的 应 用 中 使 用 了 迭代 器 ， 在 哪 ? 
请 看 代码 清单 20-3， 注 意 这 上 段 话 : for(IProject project:projectList)， 它 为 
什么 能 够 运行 起 来 ? 还 不 是 因为 ArrayList 已 经 实现 了 iterator() 方 法 ， 我 
们 才能 如 此 简单 地 应 用 。 


从 JDK 1.2 版 本 开始 增加 java.util.Iterator 这 个 接口 ， 并 逐步 把 
Iterator 应 用 到 各 个 聚集 类 (Collection) 中 ， 我 们 来 看 JDK 1.5 的 API 帮 
助 文件 ， 你 会 看 到 有 一 个 叫 java.util.Iterable 的 接口 ， 看 看 有 多 少 个 接 
口 继承 了 它 : 


BeanContext,BeanContextServices,BlockingQueue<E>,Collection<E>,List 


<E>,Queue<E>,Set<E>,SortedSet<E>， 再 看 看 有 它 多 少 个 实现 类 : 

AbstractCollection, AbstractList, AbstractQueue, AbstractSequentialList, Abs 
tractSet,ArrayBlockingQueue, ArrayList, AttributeList, BeanContextServices 
Support, BeanContextSupport,ConcurrentLinkedQueue,CopyOn WriteArray 
List,CopyOnWriteArraySet, DelayQueue, EnumSet, HashSet,JobStateReason 
s,LinkedBlockingQueue,LinkedHashSet,LinkedList, PriorityBlockingQueue 


,PriorityQueue, RoleList, RoleUnresolvedList, Stack, SynchronousQueue, Tree 


Set,Vector， 基 本 上 我 们 经 常 使 用 的 类 都 在 这 个 表 中 了 ， 也 正 是 因为 


Java 把 述 代 侣 模式 已 经 融入 到 基本 API 中 了 ， 我 们 才能 如 此 轻松 、 便 
捷 。 


我 们 再 来 看 看 Iterable 接 口 。java.util.Iterable 接 口 只 有 一 个 方法 : 
iterator()， 也 就 说 ， 通 过 iterator() 这 个 方法 去 遍历 聚集 类 中 的 所 有 方法 
或 属性 ， 基 本 上 现在 所 有 的 高 级 语言 都 有 Iterator 这 个 接口 或 者 实现 ， 
Java 已 经 把 迭代 器 给 我 们 准备 好 了 ， 我 们 再 去 写 送 代 器 ， 就 有 点 多 余 
了 。 所 以 呀 ， 这 个 迭代 器 模式 也 有 点 没落 了 ， 基 本 上 很 少 有 项 目 再 独 
立 写 迭代 器 了 ， 直 接 使 用 Collection 下 的 实现 类 就 可 以 完美 地 解决 问 


题 。 


迭代 右 现 在 应 用 得 越 来 越 广泛 了 ， 甚 至 已 经 成 为 一 个 最 基础 的 工 
具 。 一 些 大 师 级 人 物 甚 至 建议 把 碗 代 吕 模式 从 23 个 模式 中 删除 ， 为 什 
么 呢 ? 吏 是 因为 现在 它 太 普通 了 ， 已 经 融入 到 各 个 语言 和 工具 中 了 ， 
比如 PHP 中 你 能 找到 它 的 身影 ，Perl 也 有 它 的 存在 ， 甚 至 是 前 台 的 页 面 
技术 AJAX 也 可 以 有 它 的 出 现 (如 在 Struts2 中 就 可 以 直接 使 用 
iterator) 。 基 本 上 ， 只 要 你 不 是 在 使 用 那些 古董 级 ( 指 版 本 号 ) 的 编 
程 语言 的 话 ， 都 不 用 目 己 动 手写 迭代 天 。 


20.4 最 佳 实践 


如 果 你 是 做 Java 开 发 ， 尽 量 不 要 自己 写 迁 代 器 模式 ! 省 省 吧 ， 使 
用 Java 提 供 的 Iterator 一 般 就 能 满足 你 的 要 求 了 。 


21.1 公司 的 人 事 染 构 是 这 样 的 吗 


各 位 读者 ， 大 家 在 上 学 的 时 候 应 该 部 学 过 “数据 结构 ”这 [课程 
吧 ， 还 记得 其 中 有 一 下 叫 “ 二 又 树 ” 吧 ， 我 们 上 学 那 会 儿 这 一 章 世 是 必 
著 内 容 ， 左 子 树 ， 右 子 树 ， 什 么 先 序 肖 历 、 后 序 过 历 ， 重 点 就 是 二 叉 
树 的 遍历 ， 我 还 记得 当时 老师 就 讽 ， 考 试 的 时 候 一 定 有 二 又 树 的 构建 
和 遍历 ， 现 在 想起 来 还 是 觉得 老师 是 正确 的 ， 树 状 结构 在 实际 中 应 用 
非常 广泛 ， 想 想 看 你 最 常 使 用 的 XML 格式 是 不 是 就 是 一 个 树 形 结 构 。 


虽 束 和 完 说 个 最 第 见 的 例子 ， 公 司 的 人 事 管理 就 古 一 个 典型 的 树 状 
结构 ， 想 想 看 你 公司 的 组 织 架 构 是 不 是 如 图 21-1 所 示 。 


财务 人 员 
员工 J 


从 最 高 的 老大 ， 往 下 一 层 一 层 的 管理 ， 最 后 到 我 们 这 层 小 兵 .….…… 
很 典型 的 树 状 结构 〈 说 明 一 下 ， 这 不 是 二 又 树 ， 有 关 二 义 树 的 定义 可 
以 翻 翻 以 前 的 教科 书 ) ， 我 们 今天 的 任务 就 是 要 把 这 个 树 状 结构 实现 
出 来 ， 并 且 还 要 把 它 裔 历 一 人 裔 ， 丈 类 似 于 阅读 你 公司 的 人 员 花 名 册 。 


从 该 树 状 结构 上 分 析 ， 有 两 种 不 同性 质 的 节点 : 有 分 文 的 节点 
(如 研发 部 经 理 ) 和 无 分 支 的 节点 〈 如 员工 A、 员 工 D 等 ) ， 我 们 增加 
一 点 学 术 术 语 上 去 ， 总 经 理 叫 做 根 世 点 (是 不 是 想到 XML 中 的 那个 根 季 
点 root， 那 就 对 了 )， 类 似 研发 部 经 理 有 分 支 的 节点 叫做 树枝 节点 ， 类 
似 员工 A 的 无 分 支 的 节点 叫做 树 时 节点 ， 都 很 形象 ， 三 个 类 型 的 世 点 ， 


那 古 不 十 定 义 三 个 类 束 可 以 ? 好 ， 我 们 按照 这 个 思路 走 下 去 ， 先 看 我 
们 目 己 设计 的 类 图 ， 如 图 21-2 所 示 。 


<<interface>> 
ILeaf 
| 
+String getInfo() 


+String getInfo() +String getInfo() 

+vold add(IBranch branch) +vold add(IBranch branch) 
+void add(ILeaf leaf) +void add(ILeaf leaf) 
+ArrayList getSubordinateInfo() +ArrayList getSubordinateInfo() 


| 


图 21-2 最 容易 想到 的 组 织 架 构 类 图 


这 个 类 图 是 初学 者 最 容易 想到 的 类 图 (首先 声明 ， 这 个 类 图 是 有 
缺陷 的 ， 如 果 你 已 经 看 明日 这 个 类 图 的 缺陷 了 ， 该 段落 束 可 以 一 目 十 
行 地 看 下 去 ， 我 们 是 循序 渐进 地 讲课 ， 一 步 一 个 脚印 ) ， 非 常 简单 ， 
我 们 来 看 一 下 如 何 实现 ， 爷 看 最 高 级 别 的 根 世 点 接口 ， 如 代码 清单 21-1 
所 


代码 清单 21-1 根 节点 接口 


public interface IRoot { 
// 得 到 总 经 理 的 信息 
public String getInfo(); 
// 总 经 理 下 边 要 有 小 兵 ， 那 要 能 增加 小 兵 ， 比 如 研发 部 总 经 理 ， 这 是 个 树 校 节 点 
public void add(IBranch branch); 
// 那 要 能 增加 树叶 节点 
public void add(ILeaf leaf ) ， 
// 既 然 能 增加 ， 那 还 要 能 够 遍历 ， 不 可 能 总 经 理 不 知道 他 手下 有 哪些 人 
public ArrayList getSubordinateInfo( ) ; 


这 个 根 世 点 的 对 象 束 是 我 们 的 总 经 理 ， 其 具体 实现 如 代码 清单 21-2 
所 示 。 


代码 清单 21-2 根 节点 的 实现 


public class Root implements IRoot { 
// 保 存根 市 点 下 的 树 校 节 点 和 树叶 市 点 ，Subordinate 的 意思 是 下 级 
private ArrayList subordinateList = new ArrayList(); 
// 根 节点 的 名 称 
private String name = ""; 
// 根 节点 的 职位 
private String position = ""; 
// 根 节点 的 薪水 
private int Salary = 0; 
// 通 过 构造 函数 传递 进来 总 经 理 的 信息 
public Root(String name,String position,int salary)t{ 
this.name = name; 
this.position = position; 
this.salary = salary; 


} 

// 增 加 树枝 节点 

public void add(IBranch branch) { 
this.subordinateList.add(branch); 


} 

// 增 加 叶子 节点 ， 比 如 秘书 ， 直 接 隶 属于 总 经 理 

public void add(ILeaf leaf) { 
this.subordinateList.add(leaf); 


} 
// 得 到 自己 的 信息 
public String getInfo() { 

String info = "",; 

info = "名 称 : "+ this,.name;; 


info = info + "Nt 职位 : " + this.position 


info = info + "Nt 薪水 : " + this.salary; 
return Info， 

} 

// 得 到 下 级 的 信息 


public ArrayList getSubordinateInfo() { 
return this.subordinateList,; 
} 


很 简单 ， 通 过 构造 画 数 传 入 参数 ， 然 后 获得 信息 ， 可 以 增加 子 树 
枝 节 点 (部门 经 理 ) 和 叶子 市 点 (秘书) 。 我 们 再 来 看 其 他 有 分 文 的 
节点 接口 ， 如 代码 清单 21-3 所 示 。 


代码 清单 21-3 其 他 有 分 文 的 节点 接口 


public interface IBranch { 
// 获 得 信息 
public String getInfo(); 
// 增 加 数据 节点 ， 例 如 研发 部 下 设 的 研发 一 
public void add(IBranch branch ) ; 
// 增 加 叶子 节 点 
public void add(ILeaf leaf); 
// 获 得 下 级 信息 
public ArrayList getSubordinateInfo( ) ; 


有 了 接口 ， 束 应 该 有 实现 ， 其 具体 的 实现 类 ， 如 代码 清单 21-4 所 
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代码 清单 21-4 分 支 的 节点 实现 


public class Branch implements IBranch { 
// 存 储 子 节 点 的 信息 
private ArrayList subordinateList = new ArrayList(); 
// 树 枝 节 点 的 名 称 
private String name="",，; 


// 树 枝 节 点 的 职位 


private String position = ""; 

// 树 校 节 点 的 薪水 

private int Salary = 0; 

// 通 过 构造 画 数 传递 树 校 节 点 的 参数 

public Branch(String name,String position,int salary)t{ 
this.name = name; 
this.position = position; 
this.salary = salary; 


} 
// 增 加 一 个 子 树枝 节点 
public void add(IBranch branch) { 

this. subordinateList.add(branch); 


} 

// 增 加 一 个 叶子 节点 

public void add(ILeaf leaf) { 
this.subordinateList.add(leaf); 


} 
// 获 得 自己 树枝 市 点 的 信息 
public String getInfo() { 
String info = ""; 
info = "名 称 : " + this.name; 
info = info + "Nt 职位 : "+ this.position; 


info = info + "Nt 薪水 : "+this.salary; 
return Info， 

} 

// 获 得 下 级 的 信息 


public ArrayList getSubordinateInfo() { 
return this.subordinateList,; 


是 总 经 理 还 是 部 门 经 理 都 是 有 子 节 点 的 存在 ， 最 终 的 子 节 点 
就 是 叶子 点 ， 其 接口 如 代码 请 单 21-5 所 示 。 


代码 清单 21-5 叶子 市 点 的 接口 


public interface ILeaf { 
// 获 得 自 己 的 信 ， / 蕊 ， 
public String getInfo(); 


叶子 太太 的 接口 人 简单， 实现 也 非常 容易 ， 如 代码 清单 21-6 所 示 。 


代码 清单 21-6 叶子 节点 的 实现 


public class Leaf implements ILeaf { 
// 叶 子 叫 什么 名 字 
private String name = "”"; 
// 叶 子 的 职位 
private String position = ""， 
// 叶 子 的 薪水 
private int Salary=0 
// 通 过 构造 函数 传递 信息 
public Leaf(String name,String position,int salary)t{ 
this.name = name; 
this.position = position; 
this.salary = salary; 


} 
// 最 小 的 小 兵 只 能 获得 自己 的 信息 了 
public String getInfo() { 


String info = "",， 
info = "名 称 : " + this.name; 
info = info + "Nt 职位 : "+ this.position; 


info = info + "Nt 薪水 : "+this.salary; 
return Info 


好 了 ， 上 所 有 的 根 节 点 、 树 枝 节 点 和 叶子 节点 都 已 经 实现 了 ， 从 总 
经 理 、 部 门 经 理 到 最 终 的 员工 都 已 经 实现 ， 然 后 的 工作 就 是 组 装 成 一 
个 树 状 结构 并 遍历 这 棵 树 ， 通 过 什么 来 完成 呢 ? 通 过 场景 类 Client 完 
成 ， 如 代码 清单 21-7 所 示 。 


代码 清单 21-7 场景 


public class Client { 
public static void main(String[] args) { 
// 首 先 产 生 了 一 个 根 节 点 
IRoot ceo = new Root(" 王 大 麻子 "， "总 经 理 ", 100000); 
// 产 生 三 个 部 门 经理 ， 也 就 是 树枝 节点 
IBranch developDep = new Branch(" 刘 大 病 子 "," 研 发 部 门 经 


理 ", 10000); 


IBranch salesDep = new Branch(" 马 二 拐子 ", "销售 部 门 经 


理 ", 20000) ; 


IBranch financeDep = new Branch(" 赵 三 驼 子 "," 财 务 部 经 
理 ", 30000)， 


// 再 把 三 个 小 组 长 产生 出 来 
IBranch firstDevGroup = new Branch(" 杨 三 也 斜 ", "开发 一 
组 组 长 ", 5000); 


IBranch secondDevGroup = new Branch(" 吴 大 棱 梭 ", "开发 
二 组 组 长 ", 6000); 
// 璋 下 的 就 是 我 们 这 些小 兵 了 ,就 是 路 人 甲 、 、 路 人 乙 


ILeaf a = new Leaf("a", "开发 人 员 ",2000); 
ILeaf b = new Leaf("b", "开发 人 员 ",2000); 
ILeaf c = new Leaf("c", "开发 人 员 ",2000); 
ILeaf d = new Leaf("d", "开发 人 员 ",2000); 
ILeaf e = new Leaf("e", "开发 人 员 ",2000); 
ILeaf f = new Leaf("f", "开发 人 员 ",2000); 
ILeaf g = new Leaf("g", "开发 人 员 ",2000); 
ILeaf h = new Leaf("h", "销售 人 员 ", 5000 ) ; 
ILeaf i = new Leaf("i", "销售 人 员 " , 4000); 
ILeaf j = new Leaf("j", "财务 人 员 ", 5000 ) ; 
ILeaf k = new Leaf("k", "CEO 秘 书 ",8000); 


ILeaf zhengLaoLiu = new Leaf(" 郑 老 六 ", "研发 部 副 


// 该 产生 的 人 都 产生 出 来 了 ， 然 后 我 们 怎么 组 装 这 棵 树 
// 首 先是 定义 总 经 理 下 有 三 个 部 门 经 理 

ceo ,add(developDep ) ， 

ceo.add(salesDep); 

ceo.add(financeDep); 

// 总 经 理 下 还 有 一 个 秘书 
ceo.add(k); 

// 定 义 研 发 部 门下 的 结构 
developDep.add(firstDevGroup); 
developDep.add(secondDevGroup); 
// 研 发 部 经 理 下 还 有 一 个 副 总 
developDep.add(zhengLaoLiu); 
// 看 看 开发 两 个 开发 小 组 下 有 什么 
firstDevGroup.add(a); 
firstDevGroup.add(b); 
firstDevGroup.add(c); 
secondDevGroup.add(d); 
secondDevGroup.add(e); 
secondDevGroup.add(f); 

// 再 看 销售 部 下 的 人 员 人 情况 
salesDep.add(h); 
salesDep.add(i); 

// 最 后 一 个 财务 


总 ", 20000) ; 


financeDep ,add(j ) ; 

// 打 印 写 完 的 树 状 结构 
System.out.println(ceo.getIinfo()); 

// 打 印 出 来 整个 树 形 
getAllSubordinateInfo(ceo.getSubordinateInfo( )); 


} 
// 遍 历 所 有 的 树枝 节点 ， 打 印 出 信息 
private static void getAllSubordinateInfo(ArrayList 
subordinateList)t{ 
int length = subordinateList.size(); 
// 定 义 一 个 ArrayList 长 度 ， 不 要 在 for 循 环 中 每 次 计算 
for(int m=0;m<length;m++){ 
Object s = subordinateList.get(m); 
if(s instanceof Leaf){ // 是 个 叶子 节点 ， 世 就 是 员 
ILeaf employee = (ILeaf)s; 
System,out,printlLn(((Leaf ) 


s).getIinfo()); 
}elsef{ 
IBranch branch = (IBranch)s; 
System.out.println(branch.getIinfo()); 
// 再 递归 调用 


getAllSubordinateInfo(branch.getSubordinateInfo()); 
} 
} 


这 个 程序 比较 长 ， 如 果 在 我 们 的 项 目 中 有 这 样 的 程序 ， 肯 定 是 
被 拉 出 来 做 典型 的 ， 你 写 一 大 坨 的 程序 给 谁 呀 ， 以 后 还 要 维护 ， 程 序 
要 短小 精 悍 ! 幸运 的 是 ， 我 们 这 是 作为 案例 来 讲解 ， 而 且 束 是 指出 这 
样 组 竣 这 柠 树 和 站 有 问题 的 ， 等 会 我 们 深入 讲解 ， 允 看 运行 结果 : 


名 称 : 王 大 麻子 “职位 :; 总 经 理 薪水 : 100000 
名 称 : 刘 大 病 子 “ 职 位 ; 研发 部 门 经 理 薪水: 10000 
名 称 : 杨 三 巧 斜 职位: 开发 一 组 组 长 ”薪水 : 5000 


名 称 : a 职位 : 开发 人 员 薪水 : 2000 
名 称 : b 职位 : 开发 人 员 薪水 : 2000 


名 称 : c 职位 : 开发 人 员 薪水 : 2000 


名 称 : 吴 大 棒 槐 ”职位 : 开发 二 组 组 长 ”薪水 : 6000 
名 称 : d 职位 : 开发 人 员 薪水 : 2000 
名 称 : e 职位 : 开发 人 员 薪水 : 2000 
名 称 : f 职位 : 开发 人 员 薪水 : 2000 
名 称 : 郑 老 六 职位 :研发 部 副 总 薪水 : 20000 
名 称 : 马 二 拐子 “职位 : 销售 部 门 经 理 ” 薪 水: 20000 
名 称 : h 职位 : 销售 人 员 薪水 : 5000 
名 称 : i 职位 : 销售 人 员 薪水 : 4000 
名 称 : 赵 三 弦子 ”职位 : 财务 部 经 理 薪水 : 30000 
名 称 : j 职位 : 财务 人 员 薪水 : 5000 
名 称 : k 职位 ，CEO 秘 书 薪水 : 8000 


和 我 们 期 望 的 结 来 一 样 ， 一 标 完 整 的 树 束 生成 了 ， 而 且 我 们 还 能 
够 遍历 。 不 错 ， 不 错 ， 但 是 看 类 图 或 程序 的 时 候 ， 你 有 没有 发 觉 有 问 
题 ? getInfo 每 个 接口 都 有 ， 为 什么 不 能 抽象 出 来 ? Root 类 和 Branch 类 有 
什么 差别 ? 根 节 点 本 身 就 是 树 术 世 点 的 一 种 ， 为 什么 要 定义 成 两 个 接 
口 两 个 类 ?如 果 我 要 加 一 个 任职 期 限 ， 你 是 不 是 每 个 类 都 需要 修改 ” 如 
果 我 要 后 序 遍 历 (从 员工 找到 他 的 上 级 领导 ) 能 做 到 吗 ? 一 一 彻底 党 


菜 了 | 


问题 很 多 ， 我 们 一 个 一 个 解决 ， 先 说 抽象 的 问题 。 我 们 确实 可 以 
把 IBranch 和 IRoot 合 并 成 一 个 接口 ， 确 认 无 疑 的 事 我 们 先 做 ， 那 我 们 就 
修改 一 下 类 图 ， 如 图 21-3 所 示 。 


仔细 看 看 这 个 类 图 ， 还 能 不 能 发 现 点 问题 。 想 想 看 接口 的 作用 是 
什么 ? 定义 一 类 事物 所 具有 的 共性 ， 那 ILeaf 和 IBranch 是 不 是 也 有 共性 


呢 ? 有 ，getInfo 方 法 ! 我 们 是 不 是 要 把 这 个 共性 也 封 靖 起 来 呢 ? 是 
的 ， 是 的 ， 提 炼 事物 的 共同 点 ， 然 后 封装 之 ， 这 是 我 们 作为 设计 专家 
的 拿手 好 戏 ， 修 改 后 的 类 图 如 图 21-4 所 示 。 


<<interface>> <<interface>> 
IBranch es ILeaf 
| | | 
+String getInfo() +String getInfo() 
+void add(IBranch branch) 


+void add(ILeaf leaf) 


+ArrayList getSubordinateInfo() 


图 21-3 整合 根 节 点 和 树枝 节点 后 的 类 图 


下 “i 
[| rr 


<<mnterface>> 
ICorp 


+String getInfo() 


<<Interface>> 
ILeaf 


图 21-4 修改 后 的 类 图 


类 图 上 增加 了 一 个 ICorp 接 口 ， 它 是 公司 所 有 人 员 信 息 的 接口 类 ， 
不 管 你 是 经 理 还 是 员工 ， 你 都 有 名 字 、 职 位 、 亲 水 ， 这 个 定义 成 一 个 
接口 没有 错 ， 但 是 你 可 能 对 于 ILeaf 接 口 持 怀 疑 状 态 ， 空 接口 有 何 意 义 
呀 ? 有 意义 ! 它 是 每 个 树 校 三 点 的 代表 ， 系 统 扩 容 的 时 候 你 就 会 发 现 
它 是 多 么 “栋梁 *。 我 们 先 来 看 新 增加 的 接口 ICorp， 如 代码 清单 21-8 所 
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代码 清单 21-8 公司 人 员 接 口 


public interface ICorp { 
// 每 个 员工 都 有 信息 ， 你 想 隐 藏 ， 门 儿 都 没有 
public String getInfo(); 


接口 很 简单 ， 只 有 一 个 方法 ， 束 古 获 得 员工 的 信息 ， 树 时节 点 是 
最 基层 的 构件 ， 我 们 先 来 看 看 它 的 接口 ， 空 接口 ， 如 代码 清单 21-9 所 
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代码 清单 21-9 树叶 接口 


public interface ILeaf extends ICorp { 


} 


树叶 接口 的 实现 类 ， 如 代码 清单 21-10 所 示 。 


代码 清单 21-10 树叶 接口 


public class Leaf implements ILeaf { 
// 小 兵 也 有 和 名称 
private String name = ""; 
// 小 兵 也 有 职位 
private String position = ""， 
// 小 兵 也 有 薪水 ， 否 则 谁 给 你 干 
private int Salary = 0; 
// 通 过 一 个 构造 函数 传递 小 兵 的 信息 
public Leaf(String name,String position,int salary)t{ 
this.name = name; 
this.position = position; 
this.salary = salary; 


} 
// 获 得 小 兵 的 信息 
public String getInfo() { 
String info = "",; 
info = "姓名 : " + this.name; 
info = info + "Nt 职位 : "+ this.position; 
info = info + "Nt 薪水 : " + this.salary 
return Info， 


演 


小 兵 就 只 有 这 些 信 息 了 ， 我 们 是 具体 干 活 的 ， 我 们 是 管理 不 了 其 
他 同事 的 ， 我 们 来 看 看 那些 经 理 和 小 组 长 是 怎么 实现 的 ， 也 就 是 
IBranch 接 口 ， 如 代码 清单 21-11 所 示 。 


代码 清单 21-11 树枝 接口 


public interface IBranch extends ICorp { 
// 能 够 增加 小 兵 (树叶 节点 ) 或 者 是 经 理 (树枝 节点 ) 
public void addSubordinate(ICorp corp); 
// 我 还 要 能 够 获得 下 属 的 信息 
public ArrayList<ICorp> getSubordinate( ) ， 
/* 本 来 还 应 该 有 一 个 方法 delSubordinate(ICorp corp)， 删除 下 属 
ee es 


接口 也 很 商 单 ， 其 实现 类 也 不 可 能 太 复 杂 ， 如 代码 请 单 21-12 所 
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代码 清单 21-12 树枝 实现 类 


public class Branch implements IBranch { 
// 领 导 也 是 人 ， 也 有 和 名字 
private String name = ""; 
// 领 导 和 领导 不 同 ， 也 是 职位 区 别 
private String position = ""; 
// 领 导 也 是 拿 薪 水 的 
private int Salary = 0; 
// 领 导 下 边 有 哪些 下 级 领导 和 小 兵 
ArrayList<ICorp> subordinateList = new ArrayList<ICorp>(); 
// 通 过 构造 函数 传递 领导 的 信息 
public Branch(String name,String position,int Salary){ 
this.name = name; 
this.position = position; 
this.salary = salary; 


} 
// 增 加 一 个 下 属 ， 可 能 是 小 头目 ， 也 可 能 是 个 小 兵 
public void addSubordinate(ICorp corp) { 


this.subordinateList.add(corp); 


} 

// 我 有 哪些 下 属 

public ArrayList<ICorp> getSubordinate() { 
return this.subordinatelList,; 


领导 也 是 人 ， 他 也 有 信息 
String getInfo() { 


String info = "",， 

info = "姓名 : " + this.name; 

info = info + "Nt 职位 : "+ this.position; 
info = info + "Nt 薪水 : " + this.salary 


return Info， 


实现 类 也 很 简单 ， 不 多 说 ， 程 序 写 得 好 不 好 ， 就 看 别人 怎么 调用 
了 ， 我 们 看 场景 类 Client， 如 代码 清单 21-13 所 示 。 


代码 清单 21-13 场景 类 a 


public class Client { 
public static void main(String[] args) { 

// 首 先是 组 装 一 个 组 织 结构 出 来 

Branch ceo = compositeCcorpTree( ) ， 
// 首 先 把 CE0 的 信息 打印 出 来 

System,.out .println(ceo.getInfo())， 
// 然 后 是 所 有 员工 信息 
System.out.printJln(getTreeInfo(ceo) ) ; 


} 

// 把 整个 树 组 装 出 来 
public static Branch compositecorpTree( ){ 

// 首 先 产 生 总 经 理 CE0 

Branch root = new Branch(" 王 大 太子 "，" 总 经 理 "，100009 ) ; 
// 把 三 个 部 门 经 理 产 生出 来 

Branch developDep = new Branch(" 刘 大 病 子 "," 研 发 部 门 经 


理 ", 10000); 


Branch salesDep = new Branch(" 马 二 拐子 ", "销售 部 门 经 
理 ", 20000); 


Branch financeDep = new Branch(" 赵 三 驼 子 ", "财务 部 经 
理 ", 30000); 


// 再 把 三 个 小 组 长 产生 出 来 
Branch firstDevGroup = new Branch(" 杨 三 七 斜 ", "开发 一 


组 长 ", 5000); 
Branch secondDevGroup = new Branch(" 吴 大 棒 梭 ", "开发 二 


组 组 长 ", 6000); 
// 把 所 有 的 小 兵 都 产生 出 来 


Leaf a = new Leaf("a", "开发 人 员 ",2000); 
Leaf b = new Leaf("b", "开发 人 员 ",2000); 
Leaf c = new Leaf("c", "开发 人 员 ",2000); 
Leaf d = new Leaf("d", "开发 人 员 ",2000); 
Leaf e = new Leaf("e", "开发 人 员 ",2000); 
Leaf f = new Leaf("f", "开发 人 员 " ,2000); 
Leaf g = new Leaf("g", "开发 人 员 ",2000); 
Leaf h = new Leaf("h", "销售 人 员 ", 5000); 
Leaf i = new Leaf("i", "销售 人 员 ", 4000); 
Leaf j = new Leaf("j", "财务 人 员 ", 5000); 
Leaf k = new Leaf("k", "CEO 秘 书 ", 8000); 


Leaf zhengLaoLiu = new Leaf (" 郑 老 六 ", "研发 部 副 经 
理 ", 20000); 
// 开 始 组 装 
//CE0 下 有 三 个 部 门 经 理 和 一 个 秘书 
root.addSubordinate(k); 
root.addSubordinate(developDep); 
root.addSubordinate(salesDep); 
root,addSubordinate(financeDep ) ， 
// 人 研发 部 经 理 
developDep.addSubordinate(zhengLaoLiu); 
developDep.addSubordinate(firstDevGroup); 
developDep.addSubordinate(secondDevGroup); 
// 看 看 两 个 开发 小 组 下 有 什么 
firstDevGroup.addSubordinate(a); 
firstDevGroup.addSubordinate(b); 
firstDevGroup.addSubordinate(c); 
secondDevGroup.addSubordinate(d); 
secondDevGroup.addSubordinate(e); 
secondDevGroup.addSubordinate(f); 
// 再 看 销售 部 下 的 人 员 人 情况 
salesDep.addSubordinate(h); 
salesDep.addSubordinate(i); 
// 最 后 一 个 财务 
financeDep.addSubordinate(j); 
return root,; 


} 
// 遍 历 整 棵 树 , 只 要 给 我 根 节 点 ， 我 怠 能 遍历 出 所 有 的 节点 
public static String getTreeInfo(Branch root){ 
ArrayList<ICorp> subordinateList = 
root .getSubordinate() ; 
String info = "",， 
for(ICorp s ;subordinateList ){ 


if(s instanceof Leaf){ // 是 员工 就 直接 获得 信息 
info = info + s.getInfo()+"\n"; 

}else{ // 是 个 小 头目 
info = info + S,getInfo() +"\n"+ 


getTreeInfo( (Branch)s); 
} 


return Info， 


证 


运行 结果 完全 相同 ， 不 再 资 述 。 通 过 这 样 构 件 ， 一 个 非常 清晰 的 
树 状 人 员 资 源 管理 图 出 现 了 ， 那 我 们 的 程序 是 否 还 可 以 优化 ? 可 以 ! 
你 看 Leaf 和 Branch 中 都 有 getInfo 人 信息， 是 不 是 可 以 抽象 ? 好 ， 我 们 抽象 
一 下 ， 如 图 21-5 所 示 。 


Client 
| 
| | 


+vold addSubordinate(Corp corp) 
+ArrayList getSubordmateInfo() 
图 21-5 精简 的 类 图 


你 一 看 这 个 图 ， 乐 了 。 能 不 乐 嘛 ， 减 少 很 多 工作 量 了 ， 接 口 没有 
了 ， 改 成 抽象 类 了 ，IBranch 接 口 也 没有 了 ， 直 接 把 方法 放 到 了 实现 类 
中 了 ， 太 精简 了 ! 而 且 场 景 类 只 认定 抽象 类 Corp 就 成 ， 那 我 们 首先 来 
看 抽象 类 ICorp， 如 代码 清单 21-14 所 示 。 


代码 清单 21-14 抽象 公司 职员 类 


public abstract class Corp { 
// 公 司 每 个 人 都 有 名 称 
private String name = ""; 
// 公 司 每 个 人 都 职位 
private String position = ""，; 
// 公 司 每 个 人 都 有 薪水 
private int salary =0; 
public Corp(String _name,String _position,int _salary)t{ 


this.name = _name; 
this.position = _position; 
this.salary = _salary; 


} 

// 获 得 员工 信息 

public String getInfo(){ 
String info = ""; 


info = "姓名 : " + this.name; 
info = info + "Nt 职位 : "+ this.position; 
info = info + "Nt 薪水 : " + this.salary， 


return Info， 


抽象 类 嘛 ， 就 应 该 抽象 出 一 些 共 性 的 东西 出 来 ， 然 后 看 两 个 具体 
的 实现 类 ， 树 叶 世 点 如 代码 清单 21-15 所 示 。 


代码 清单 21-15 树叶 节点 


public class Leaf extends Corp { 
// 就 写 一 个 构造 画 数 ， 这 个 是 必需 的 
public Leaf(String _name,String _position,int _salary)t{ 
super(_name,_position,_salary); 
} 


这 个 精简 得 比较 多 ， 几 行 代码 就 完成 了 ， 确 实 束 应 该 这 样 ， 下 面 
是 小 头目 的 实现 类 ， 如 代码 请 单 21-16 所 示 。 


代码 清单 21-16 树枝 节点 


public class Branch extends Corp { 
// 领 导 下 边 有 哪些 下 级 领导 和 小 兵 
ArrayList<Corp> SubordinateList = new ArrayList<Corp>(); 
// 构 造 玉 数 是 必需 的 
public Branch(String _name,String _position,int _salary)t{ 
super(_name,_position,_salary); 


} 

// 增 加 一 个 下 属 ， 可 能 是 小 头目 ， 也 可 能 是 个 小 兵 

public void addSubordinate(Corp corp) { 
this.subordinateList.add(corp); 


} 

// 我 有 哪些 下 属 

public ArrayList<Corp> getSubordinate() { 
return this.subordinatelList,; 

} 


场景 类 中 构建 树 形 结构 ， 并 进行 通 历 。 组 装 没 有 变化 ， 授 历 组 织 
机 构 数 稍 有 变化 ， 如 代码 清单 21-17 所 示 。 


代码 清单 21-17 稍稍 修改 的 场景 


public class Client { 
// 遍 历 整 棵 树 , 只 要 给 我 根 节 点 ， 我 就 能 遍历 出 所 有 的 市 点 
public static String getTreeInfo(Branch root){ 
ArrayList<Corp> SubordinateList = 
root .getSubordinate() ; 
String info = ""”; 
for(Corp s :subordinateList){ 
if(s instanceof Leaf){ // 是 员工 就 直接 获得 信息 
info = info + s.getIinfo()+"\n"; 
}else{ // 是 个 小 头目 
info = info+s.getInfo()+"\n"+ 


getTreeInfo( (Branch)s); 
} 


return Info， 


场景 类 中 main 方 法 没有 变动 ， 请 参考 代码 清单 21-7 所 示 ， 不 再 敖 
述 。 通 历 组 织 机 构 树 的 getTreeInfo 稍 有 修改 ， 束 是 把 用 到 ICorp 接 口 的 
地 方 修改 为 Corp 抽 象 类 ， 其 他 保持 不 变 ， 运 行 结果 相同 。 这 就 是 组 合 
模式 。 


21.2 组 合 模式 的 定义 


组 合 模式 (Composite Pattern) 也 叫 合成 模式 ， 有 时 又 叫做 部 分 -整体 
模式 (Part-Whole) ， 主 要 是 用 来 描述 部 分 与 整体 的 关系 ， 其 定义 如 
下 : 


Compose objects into tree structures to represent part-whole 
hierarchies.Composite lets clients treat individual objects and compositions 
of objects uniformly.，( 将 对 象 组 合成 树 形 结构 以 表示 “部 分 -整体 ”的 层次 
结构 ， 使 得 用 户 对 单个 对 象 和 组 合 对 象 的 使 用 具有 一 致 性 。) 


组 合 模式 的 通用 类 图 ， 如 图 21-6 所 示 。 


+Operation() 


| 
+Add(Parameterl: Component) 
+Remove(Parameterl: Component) 


+GetChild(int) 


图 21-6 组 合 模 式 通 用 类 图 


我 们 先 来 说 说 组 合 模式 的 几 个 角色 。 


@ Component 抽 象 构件 角色 


定义 参加 组 合 对 象 的 共有 方法 和 属性 ， 可 以 定义 一 些 默 认 的 行为 
或 属性 ， 比 如 我 们 例子 中 的 getInfo 就 封装 到 了 抽象 类 中 。 


e Leaf 叶 子 构件 
叶子 对 象 ， 其 下 再 也 没有 其 他 的 分 支 ， 也 就 是 扬 历 的 最 小 单位 。 
e Composite 树 枝 构 件 


树 校 对 象 ， 它 的 作用 是 组 合 树枝 节点 和 叶子 节点 形 成 一 个 树 形 结 
构 。 


我 们 来 看 组 合 模式 的 通用 源 代码 ， 首 先 看 抽象 构件 ， 它 是 组 合 模 
式 的 精 散 ， 如 代码 清单 21-18 所 示 。 


代码 清单 21-18 抽象 构件 


public abstract class a { 
// 个 体 和 整体 都 具有 的 共 
public void doSomething( )f 
// 编 写 业 务 逻 辑 
} 


组 合 模式 的 重点 束 在 树 校 构件 ， 其 通用 代码 如 代码 清单 21-19 所 


代码 清单 21-19 树枝 构件 


public class Composite extends Component { 
// 构 件 容 器 
private ArrayList<Component> componentArrayList = new 
ArrayList<Component>( ) ; 
// 增 加 一 个 叶子 构件 或 树 校 构件 
public void add(Component component){ 
this.componentArrayList.add(component ) ; 


} 

// 删 除 一 个 叶子 构件 或 树 校 构件 

public void remove(Component component){ 
this.componentArrayList.remove(component); 


} 

// 获 得 分 支 下 的 所 有 叶子 构件 和 树 校 构件 

public ArrayList<Component> getChildren(){ 
return this.componentArrayList; 

} 


树叶 节点 是 没有 子 下 级 对 象 的 对 象 ， 定 义 参 加 组 合 的 原始 对 象 行 
为 ， 其 通用 源 代码 如 代码 清单 21-20 所 示 。 


代码 清单 21-20 树叶 构件 


public class Leaf extends Component { 
hs 

* 可 以 履 写 父 类 方法 

* public void doSomething(){ 


We: 
*/ 


场景 类 负责 树 状 结构 的 建立 ， 并 可 以 通过 递归 方式 遍历 整个 树 ， 
如 代码 清单 21-21 所 示 。 


代码 清单 21-21 场景 


public class Client { 
public static void main(String[] args) { 

// 创 建 一 个 根 节 点 
Composite root = new Composite(); 
root ,doSomething() ; 

// 创 建 一 个 树枝 构件 

Composite branch = new Composite( ); 
// 创 建 一 个 叶子 市 点 
Leaf leaf = new Leaf(); 
// 建 立 整体 
root.add(branch); 
branch.add(leaf ) ， 


} 
// 通 过 递归 遍历 树 
public static void display(Composite root){ 
for(Component c:root.getchildren())t{ 
if(c instanceof Leaf){ // 叶 子 节点 
c.doSsomething(); 
}else{f // 树 枝 节 点 
display( (Composite)c); 
} 


各 位 可 能 已 经 看 出 一 些 问题 7， 组 合 模式 是 对 依赖 倒转 原则 的 破 
坏 ， 但 是 它 还 有 其 他 类 型 的 变形 ， 面 向 对 象 束 是 这 么 多 的 形态 和 变 
化 ， 请 读 首 继续 阅读 下 去 ， 束 会 找到 解决 方案 。 


21.3 组 合 模 式 的 应 用 
21.3.1 组 合 模式 的 优点 


e 局 层 模块 调用 信 单 


一 棵 树 形 机 构 中 的 所 有 节点 都 是 Component， 局 部 和 整体 对 调用 
者 来 说 没有 任何 区 别 ， 也 殊 是 说 ， 高 层 模 块 不 必 关 心目 己 处 理 的 是 单 
个 对 象 还 是 整个 组 合 结构 ， 人 简化 了 高 层 模块 的 代码 。 


e 下 点 目 由 增加 


使 用 了 组 合 模 式 后 ， 我 们 可 以 看 看 ， 如 采 想 增加 一 个 树枝 节点 、 
树叶 节点 是 不 是 都 很 容易 ， 只 要 找到 它 的 父 世 点 吏 成 ， 非 党 容易 扩 
展 ， 符 合 开 闭 原则 ， 对 以 后 的 维护 非常 有 利 。 


21.3.2 组 合 模式 的 缺点 


组 合 模式 有 一 个 非常 明显 的 缺点 ， 看 到 我 们 在 场景 类 中 的 定义 ， 
提 到 树叶 和 树 校 使 用 时 的 定义 了 吗 ? 直接 使 用 了 实现 类 ! 这 在 面 同 接 
口 编程 上 是 很 不 恰当 的 ， 与 依赖 倒置 原则 冲突 ， 读 者 在 使 用 的 时 候 要 
著 虚 清楚 ， 它 限制 了 你 接口 的 影响 范围 。 


21.3.3 组 合 模式 的 使 用 场景 


e 维护 和 展示 部 分 -整体 关系 的 场景 ， 如 树 形 菜单 、 文 件 和 文件 夹 
管理 。 


e 从 一 个 整体 中 能 够 独立 出 部 分 模块 或 功能 的 场景 。 


21.3.4 组 合 模式 的 注意 事项 


只 要 是 树 形 结构 ， 就 要 考虑 使 用 组 合 模式 ， 这 个 一 定 要 记 住 ， 只 
要 是 要 体现 局 部 和 整体 的 关系 的 时 候 ， 而 且 这 种 关系 还 可 能 比较 深 ， 
考虑 一 下 组 合 模式 吧 。 


21.4 组 合 模式 的 扩展 


21.4.1 真实 的 组 合 模式 


什么 是 真实 的 组 合 模式 ? 就 是 你 在 实际 项 目 中 使 用 的 组 合 模式 ， 而 
不 是 仅仅 依照 书本 上 学 习 到 的 模式 ， 它 是 “实践 出 真知 ”。 在 我 们 的 例子 
中 ， 经 过 精简 后 ， 确 实 是 类 、 接 口 减少 了 很 多 ， 而 且 程 序 也 简单 很 多 ， 
但 是 大 家 可 能 还 是 很 迷茫 ， 这 个 Client 程 序 并 没有 改变 多 少 呀 ， 非 常 正 
确 ， 树 的 组 装 是 跑 不 了 的 ， 你 要 知道 在 项 目 中 使 用 关系 型 数据 库 来 存储 
这 些 信 息 ， 你 可 以 从 数据 库 中 直接 提取 出 哪些 人 要 分 配 到 树 校 ， 哪 些 人 
要 分 配 到 树叶， 树 权 与 树 枢 、 树 叶 的 关系 等 ， 这 些 都 是 由 相关 的 业务 人 
员 维 护 到 数据 库 中 的 ， 通 常 这 里 是 把 数据 存放 到 一 张 单独 的 表 中 ， 表 结 
构 如 图 21-7 所 示 。 


1 CEO 合 


总 经 理 NULL 
developDep 研发 部 经 理 害 CEO 
salesDep 销售 部 经 理 否 CEO 
financeDep 财务 部 经 理 否 CEO 

k 总 经 理 秘书 是 CEO 
a 员工 A 是 developDep 
b 员工 B 是 salesDep 


图 21-7 关系 数据 库 中 存储 的 树 形 结构 


这 张 数据 表 定 义 了 一 个 树 形 结构 ， 我 们 要 做 的 就是 从 数据 库 中 把 它 
读 取出 来 ， 然 后 展现 到 前 台 上 ， 用 for 循 环 加 上 递归 就 可 以 完成 这 个 读 
取 。 用 了 数据 库 后 ， 数 据 和 逮 辑 已 经 在 表 中 定义 好 了 ， 我 们 直接 读 取 放 
到 树 上 束 可 以 了 ， 这 个 还 是 比较 容易 做 的 ， 大 家 不 妨 目 己 考 虑 一 下 。 


这 才 是 组 合 模 式 的 真实 引用 ， 它 依 徘 了 关系 数据 库 的 非 对 象 存 储 性 
能 ， 非 党 方便 地 保存 了 一 个 树 形 结构 。 大 家 可 以 在 项 目 中 考虑 采用 ， 想 
想 看 现在 还 有 哪个 项 目 不 使 用 关系 型 数据 库 呢 ? 


21.4.2 透明 的 组 合 模式 


组 合 模式 有 两 种 不 同 的 实现 : 透明 模式 和 安全 模式 ， 我 们 上 面 讲 的 
就 是 安全 模式 ， 那 透明 模式 是 什么 样子 呢 ? 透明 模式 的 通用 类 图 ， 如 图 
21-8 所 示 。 


+Operation() 

+Add(Parameterl: Component) 
+Remove(Parameterl: Component) 
+GetChild(mt) 


图 21-8 透明 模式 的 通用 类 图 


我 们 与 图 21-6 所 示 的 安全 模式 类 图 对 比 一 下 就 非常 清楚 了， 透明 模 
式 是 把 用 来 组 合 使 用 的 方法 放 到 抽象 类 中 ， 比 如 add()、remove0) 以 及 
getChildren 等 方法 (顺便 说 一 下 ，getChildren 一 般 返 回 的 结果 为 Tterable 
的 实现 类 ， 很 多 ， 大 家 可 以 看 JDK 的 帮助 ) ， 不 管 叶子 对 象 还 是 树 梳 对 
象 都 有 相同 的 结构 ， 通 过 判断 是 getChildren 的 返回 值 确认 是 叶子 节点 还 
是 树枝 节点 ， 如 果 处 理 不 当 ， 这 个 会 在 运行 期 出 现 问 题 ， 不 是 很 建议 的 
方式 ;安全 模式 就 不 同 了 ， 它 是 把 树枝 节点 和 树叶 节点 彻底 分 开 ， 树 枝 
节点 单独 拥有 用 来 组 合 的 方法 ， 这 种 方法 比较 安全 ， 我 们 的 例子 使 用 了 
安全 模式 。 


由 于 透明 模式 的 使 用 者 还 是 比较 多 ， 我 们 也 把 它 的 通用 源 代码 共 圣 
出 来 ， 甫 先 看 抽象 构件 ， 如 代码 清单 21-22 所 示 。 


代码 清单 21-22 抽象 构件 


public abstract class Component { 
// 个 体 和 整体 都 具有 的 共享 
public void doSomething(){ 
// 编 写 业 务 逻 辑 


} 

// 增 加 一 个 叶子 构件 或 树 校 构件 
public abstract void add(Component component); 
// 删 除 一 个 叶子 构件 或 树 校 构件 
public abstract void remove(Component component); 
// 获 得 分 支 下 的 所 有 叶子 构件 和 树 校 构件 
public abstract ArrayList<Component> getCchildren(); 


和 m 


抽象 构件 定义 了 树 校 太 点 和 树叶 市 点 都 必须 具有 的 方法 和 属性 ， 这 
样 树 校 太 点 的 实现 就 不 需要 任何 变化 ， 如 代码 清单 21-19 所 示 。 


树叶 节点 继承 了 Component 抽 象 类 ， 不 想 让 它 改 变 有 点 难 ， 它 必须 
实现 三 个 抽象 方法 ， 怎 么 办 ? 好 办 ， 给 个 空 方法 ， 如 代码 清单 21-23 所 


人 小 ° 


代码 清单 21-23 树叶 节点 


public class Leaf extends Component { 
@Deprecated 
public void add(Component component) throws 
UnsupportedOperationException{ 
// 空 实现 , 直接 抛弃 一 个 "不 支持 请 求 "异常 


throw new UnsupportedOperationException(); 


} 

@Deprecated 

public void remove(Component component )throws 
UnsupportedOperationExceptiont{ 


// 空 实现 
throw new UnsupportedOperationException(); 
@Deprecated 
public ArrayList<Component> getCchildren( )throws 
UnsupportedOperationExceptiont{ 
// 空 实现 
throw new UnsupportedOperationException(); 


为 什么 要 加 个 Deprecated 注 解 呢 ?就 是 在 编译 器 期 告诉 调用 者 ， 你 
可 以 调 我 这 个 方法 ， 但 是 可 能 出 现 错误 哦 ， 我 已 经 告诉 你 “该 方法 已 经 
失效 ”了 ， 你 还 使 用 那 在 运行 期 也 会 抛 出 UnsupportedOperationException 


配方 全 
开 吓 。 


在 透明 模式 下 ， 明 历 整个 树 形 结构 是 比较 容易 的 ， 不 用 进行 强制 类 
型 转换 ， 如 代码 清单 21-24 所 示 。 


代码 清单 21-24 树 结 构 遍 历 


public class Client { 
// 通 过 递归 遍历 树 
public static void display(Component root)t{ 
for(Component c:root.getchildren())t 
if(c instanceof Leaf){ // 叶 子 节 点 
c.doSsomething(); 
}elsef{ // 树 枝 节点 
display(c); 
} 


仅仅 在 遍历 时 不 再 进行 牵制 的 类 型 转化 了 ， 其 他 的 组 竣 则 没有 任何 
变化 。 透 明 模式 的 好 处 束 是 它 基 本 遵循 了 依赖 倒转 原则 ， 方 便 系统 进 


扩展 ” 


21.4.3 组 合 模式 的 遍历 


我 们 在 上 面 也 还 拓 到 了 一 个 问题 ， 就 是 树 的 让 历 问题 ， 从 上 到 下 遍 
历 没有 问题 ， 但 是 我 要 是 从 下 往 上 过 历 呢 ? 比如 组 织 机 构 这 棵 树 ， 我 从 
中 抽取 一 个 用 户 ， 要 找到 它 的 上 级 有 哪些 ， 下 级 有 哪些 ， 怎 么 处 理 ? 想 
想 ， 再 想 想 ! 想 出 来 了 吧 ， 我 们 对 下 答案 ， 类 图 如 图 21-9 所 示 。 


| | 
+String getInfo() 


#void setParent(Corp corp) 
+Corp getParent() 


| 


+void addSubordinate(Corp corp) 
+ArrayList getSubordinateInfo() 


图 21-9 增加 父 查 询 的 类 图 


看 类 图 中 ， 在 Corp 类 中 增加 了 两 个 方法 ，setParent 是 设置 父 节点 是 
谁 ，getParent 是 查找 父 节 点 是 谁 ， 我 们 来 看 一 下 程序 的 改变 ， 如 代码 清 
单 21-25 所 示 。 


代码 清单 21-25 抽象 构件 


public abstract class Corp { 
// 公 司 每 个 人 都 有 名 称 
private String name = "",， 
// 公 司 每 个 人 都 职位 
private String position = ""， 
// 公 司 每 个 人 都 有 薪水 
private int salary =0; 
// 父 节点 是 谁 
private Corp parent = null; 
public Corp(String _name,String _position,int _salary)t 


this.name = _name， 
this.position = _position; 
this.salary = _salary; 


} 
// 获 得 员工 信息 
public String getInfo(){ 
String info = "",， 
info = "姓名 : " + this.name， 
info = info + "Nt 职位 : "+ this.position; 
info = info + "Nt 薪水 : " + this.salary; 
return info; 


// 设 置 父 忆 点 

protected void setParent(Corp _parent)t{ 
this.parent = _parent,; 

// 得 到 父 节 友 


public Corp getParent( ){ 
return this.parent,; 
} 


如 代码 清单 21-26 所 示 。 


代码 清单 21-26 树枝 构件 


public class Branch extends Corp { 
// 领 导 下 边 有 哪些 下 级 领导 和 小 兵 
ArrayList<Corp> SubordinateList = new ArrayList<Corp>(); 
// 构 造 画 数 是 必需 的 
public Branch(String _name,String _position,int _salary)t{ 
super(_name,_position,_salary); 
} 


// 增 加 一 个 下 属 ， 可 能 是 小 头目 ， 也 可 能 是 个 小 其 
public void addSubordinate(Corp corp) { 


人 州 


corp.setParent(this); // 设 置 父 节点 
this.subordinateList.add(corp); 


} 

// 我 有 哪些 下 属 

public ArrayList<Corp> getSubordinate() { 
return this.subordinatelList; 

} 


镍 管 是 树枝 节点 还 是 树叶 市 点 ， 在 每 个 节点 都 增加 了 一 个 属性 ， 父 
市 点 对 象 ， 这 样 在 树枝 市 点 增加 子 市 点 或 叶子 节点 古 设置 父 季 护 ， 然 后 
你 看 整 棵 树 除了 根 节 点 外 每 个 节点 都 有 一 个 父 方 点 ， 剩 下 的 事情 还 不 好 
处 理 吗 ? 每 个 节点 上 都 有 父 忆 点 了 ， 你 要 往 上 找 ， 那 束 找 吗 ! 大 家 有 目 己 
考虑 一 下 ， 写 个 find 方 法 ， 然 后 一 步 一 步 往 上 找 ， 非 党 简单 的 方法 ， 这 
里 就 不 再 资 述 。 


有 了 这 个 parent 属 性 ， 什 么 后 序 这 历 (从 下 往 上 找 ; 、 中 序 遇 历 
(从 中 间 某 个 环 太 往 上 或 往 下 遍历 都 解决 了 ， 这 个 就 不 多 说 了 。 


再 提 一 个 问题 ， 树 时 节点 和 树 校 节 点 是 有 顺序 的 ， 你 不 能 乱 排 ， 怎 
么 办 ? 比如 我 们 上 面 的 例子 ， 人 研发 一 组 下 边 有 3 个 成 员 ， 这 3 个 成 员 要 进 
行 排序 (在 机 关 里 这 叫做 排 位 ， 同 样 是 同事 也 有 个 先后 升迁 顺序 ) ， 你 
皇 么 处 理 ? 问 我 呀 ， 问 你 呢 ， 好 好 想 想 ， 以 后 用 得 着 的 ! 


21.5 最 佳 实践 


组 合 模式 在 项 目 中 到 处 都 有 ， 比 如 现在 的 页 面 结构 一 般 都 是 上 下 
结构 ， 上 面 放 系统 的 Logo， 下 边 分 为 两 部 分 : 左边 是 导航 菜单 ， 右 边 
是 展示 区 ， 左 边 的 导航 亲 时 一般 都 是 树 形 的 结构 ， 比 较 清晰 ， 有 非常 
多 的 JavaScript 源 码 实现 了 类 似 的 树 形 菜单 ， 大 家 可 以 到 网 上 搜索 一 
下 


还 有 ， 大 家 常用 的 XML 结 构 也 是 一 个 树 形 结构 ， 根 节点 、 元 素 市 
点 、 值 元 素 这 些 都 与 我 们 的 组 合 模式 相 匹配 ， 之 所 以 本 章节 不 以 XML 
为 例子 讲解 ， 是 因为 很 少 有 人 还 直接 读 写 XML 文 件 ， 一 般 都 是 用 
JDOM 或 者 DOM4J 了 。 


还 有 一 个 非常 重要 的 例子 : 我 们 目 己 本 身 也 是 一 个 树 状 结构 的 一 
个 树 权 或 树叶 。 根 据 我 能 够 找到 我 的 父母 ， 根 据 父亲 又 能 找到 和 爷 分 奶 
奶 ， 根 据 母 杀 能 够 找到 外 公 外 姿 等 ， 很 典型 的 树 形 结构 ， 而 且 还 很 规 
范 (这 个 要 是 不 规范 那 肯定 乱 套 了 ) 。 


第 22 章 ”观察 者 模式 


22.1 昔 非 子 喘 边 的 卧 压 十 谁 派 来 的 


《孙子 兵法 》 有 云 :“ 知 彼 知己 ， 百 战 不 列 ; 不 知 彼 而 知己 ， 一 胜 
一 负 ; 不 知 彼 ， 不 知已 ， 每 战 必 列 ”， 那 怎么 才能 知己 知 彼 呢 ?知己 十 
很 容易 的 ， 自 己 的 军队 哪 ， 很 容易 知 根 知 底 ， 那 怎么 知 彼 呢 ?安插 间 
谍 是 个 好 办 法 ， 这 是 古今 中 外 屡 试 不 夹 的 方法 ， 我 们 今天 束 来 讲 一 个 
间 诬 的 故事 。 


韩非子 大 家 都 应 该 记得 吧 ， 法 家 的 代表 人 物 ， 主 张 建 立法 制 社 
会 ， 实 施 重 如 制度 ， 真 是 非常 有 远见 呀 ! 看 看 现在 社会 在 呼吁 什么 ， 
建立 法 制 化 的 社会 ， 这 在 2000 多 年 前 就 已 经 提出 了 。 大 家 可 能 还 不 知 
道 ， 法 家 还 有 一 个 非常 重要 的 代表 人 物 一 一 李斯 。 李 斯 是 泰国 的 丕 
相 ， 最 终 伞 残 妨 车 窑 的 那 位 ， 李 斯 和 韩非子 都 是 厨子 的 学 生 ， 李 斯 是 
师兄 ， 韩 非 子 是 师 计 ， 奉 干 年 后 ， 人 李斯 成 为 最 强 诸侯 国友 国 的 上 尉 ， 
致力 于 统一 全 国 ， 于 古 安 插 了 间 诬 到 各 个 国家 的 重要 人 物 的 映 边 ， 以 
获取 必要 的 信息 ， 韩 非 子 作为 韩国 的 重量 级 人 物 ， 喘 边 目 然 有 不 少 间 
诬 ， 韩 非 子 做 的 事 ， 人 李斯 剖 了 如 指 掌 ， 那 可 是 相隔 千里 ! 皇 么 做 到 的 
呢 ? 间谍 呀 ! 我 们 先 通过 程序 把 这 个 过 程 展现 一 下 ， 看 看 李斯 是 怎么 
监控 韩非子 的 ， 先 看 两 个 主角 的 类 图 ， 如 图 22-1 所 示 。 
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图 22-1 监控 者 和 被 监控 者 


区 
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仅 有 这 两 个 对 象 还 是 不 够 的 ， 我 们 要 解决 的 是 李斯 是 怎么 监控 韩 
非 子 的 ? 创建 一 个 后 台 线 程 一 直 处 于 运行 状态 ， 一 旦 发 现 韩非子 在 吃 
饭 或 者 娱乐 就 触发 事件 ?这 是 真实 世界 的 翻版 ， 安 排 了 一 个 间谍 ， 观 


察 韩非子 的 生活 起 大， 并 上 报 给 他 斯， 然后 李斯 再 触发 update 事 件 ， 类 
图 继续 扩充 ， 如 图 22-2 所 示 。 


监控 者 获得 需要 信息 后 的 活动 、 


<<Interface>> 
ILiSi 


SC 
+void update(Strng context) 


| 到 
被 监控 者 吃饭 、 娱 乐 


<<nterface>> 
IHanFeiZi 


t+void haveBreakfast() 
t+void haveFun() 


人 


-boolean 1SHavimgBreakfast 
-boolean isHavingFun 


. 


+getter/setter isHavingBreakfast() 
+getter/setter isHavingFun() 


图 22-2 通过 后 台 线 程 监控 


这 个 类 图 应 该 是 程序 员 最 容易 想到 的 ， 你 要 监控 ， 我 束 给 你 找 个 
间谍 角色 (Spy 类 ) ， 我 们 来 看 程序 的 实现 ， 先 看 我 们 的 主角 韩非子 的 
接口 《类似 于 韩非子 这 样 的 人 ， 被 观察 者 角色 ) ， 如 代码 清单 22-1 所 


尔 。 


代码 清单 22-1 被 观察 者 接口 


public interface IHanFeizZi { 
// 韩 非 子 也 是 人 人， 也 要 吃 早饭 的 
public void haveBreakfast() ; 
// 韩 非 子 也 是 人 ， 是 人 就 要 娱乐 活动 


public void haveFun(); 


对 接口 进行 扩充 ， 增 加 了 两 个 状态 isHavingBreakfast (是 否 在 吃 早 
饭 ) 和 isHavingFun 〈 是 否 在 娱乐 ) ， 以 方便 Spy 进行 监控 ， 如 代码 清单 
22-2 所 示 。 


代码 清单 22-2 具体 的 被 观察 者 


public class HanFeiZi implements IHanFeiZif{ 


// 韩 非 子 是 否 在 吃饭 ， 作 为 监控 的 判断 标准 


private boolean isHavingBreakfast = false; 
// 韩 非 子 是 否 在 娱乐 

private boolean isHavingFun = false; 

// 韩 非 子 要 吃饭 了 


public void haveBreakfast( ){ 
System.out.println(" 韩 非 子 :开始 吃饭 了 ..."); 
this.isHavingBreakfast =true; 


} 

// 韩 非 子 开始 娱乐 了 

public void haveFun(){ 
System,out,println(" 韩 非 子 : 开 始 娱乐 了 . . .") ; 


this.isHavingFun = true; 


} 

// 以 下 是 bean 的 基本 方法 ，getter/setter， 不 多 说 

public boolean isHavingBreakfast() { 
return isHavingBreakfast,; 


public void setHavingBreakfast(boolean isHavingBreakfast) { 
this.isHavingBreakfast = isHavingBreakfast; 


public boolean isHavingFun() { 
return isHavingFun; 


public void setHavingFun(boolean isHavingFun) { 
this.isHavingFun = isHavingFun; 
} 


en, 个 就 没有 在 类 图 中 表示 出 来 ， 比 较 
简单 ， 通 过 isHavingBreakfast 和 isHavingFun 这 两 个 布尔 型 变量 来 判断 韩 
非 子 是 否 在 吃 匆 或 者 娱乐 ， 娃 非 子 属 于 被 观察 者 ， 那 还 有 观察 者 李 
斯 ， 我 们 来 看 李斯 的 接口 ， 如 代码 清单 22-3 所 示 。 


代码 清单 22-3 抽象 观察 者 


public interface ILiSi { 
// 一 发 现 别人 有 动静 ， 自 己 也 要 行动 起 来 


public void update(String context); 


李斯 这 类 人 比较 简单 ， 一 发 现 自 己 观察 的 对 象 发 生 了 变化 ， 比 如 
民 饭 、 娱 乐 ， 上 自己 立刻 也 要 行动 起 来 ， 怎 么 行动 呢 ? 如 代码 清单 22-4 所 


外 


代码 清单 22-4 韩非子 


public class LiSi implements ILiSi{ 
// 首 先 李 斯 是 个 观察 者 ， 一 旦 韩非子 有 活动 ， 他 就 知道 ， 他 就 要 疝 老 板 汇 报 
public void update(String str)t{ 
System.out.printLn(" 李 斯 :观察 到 韩非子 活动 ， 开 始 同 老板 汇报 


到 
this.reportToQinShiHuang(str); 


System.out.println(" 李 斯 : 汇报 完毕 .. .Nn") ， 


} 

// 汇 报 给 秦 始 旺 

private void reportToQinShiHuang(String reportContext){ 
System.out .println(" 李 斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 --- 


>"+reportContext ) ; 


} 


两 个 重量 级 的 人 物 都 定义 出 来 了 ， 间 谍 这 个 “里吉 ”小 人 是 不 是 也 
要 登台 了 ， 如 代码 清单 22-5 所 示 。 


代码 清单 22-5 间谍 


class Spy extends Threadt{ 

private HanFeiZi hanFeizi; 

private LiSi 1iSi,; 

private String type; 

// 通 过 构造 函数 传递 参数 ， 我 要 监控 的 是 谁 ， 谁 来 监控 ， 要 监控 什么 

public Spy(HanFeiZi _hanFeizZi,LiSi _1iSi,String _type)t{ 
this.hanFeizi =_ hanFeizi,; 
this.1iSi = _1iSi; 
this.type _type; 


Q@Override 
public void run()t{ 
while(true)t{ 
if(this,type,edquals("breakfast") ){ // 监 控 是 否 在 


// 如 果 发 现 韩非子 在 吃饭， 就 通知 李斯 

if(this.hanFeizi.isHavingBreakfast())t{ 
this.1iSi,update(" 韩 非 子 在 吃饭 ") ; 
// 重 置 状 态 ， 继 续 监 控 


this.hanFeizZi.setHavingBreakfast (false); 


}else{// 监 控 是 否 在 娱乐 
if(this.hanFeizi.isHavingFun())t{ 
this.1iSi,update(" 韩 非 子 在 娱乐 " ) ; 


this.hanFeizZi.setHavingFun(false); 


} 


监控 程序 继承 了 java.lang.Thread 类 ， 可 以 同时 启动 多 个 线程 进行 监 
挖 ，Java 的 多 线程 机 制 还 是 比较 人 简单 的 ， 继 承 Thread 类 ， 重 写 run() 方 


法 ， 然 后 new SubThread()， 再 然后 subThread.start() 就 可 以 启动 一 个 线程 
了 。 我 们 建立 一 个 场景 类 来 回顾 一 下 这 段 历 史 ， 如 代码 清单 22-6 所 示 。 


代码 清单 22-6 场景 类 


public class Client { 
public static void main(String[] args) throws 
InterruptedException { 
// 定 义 出 韩非子 和 李斯 
LiSi 1iSi = new LiSi(); 
HanFeizZi hanFeizZi = new HanFeizZi(); 
// 观 察 早餐 
Watch watchBreakfast = new 
watch(hanFeizi,1iSi,"breakfast"); 
// 开 始 启动 线程 ， 监 控 
watchBreakfast. start( ); 
// 观 察 娱乐 情况 
Watch watchFun = new Watch(hanFeizi,1iSi,"fun"); 
watchFun.start(); 
// 然 后 我 们 看 看 韩非子 在 干什么 
Thread.sleep(1000) ， // 主 线程 等 待 1 秒 后 后 再 往 下 执行 
hanFeizi.haveBreakfast( ) ; 
// 韩 非 子 娱乐 了 
Thread. sleep(1000); 
hanFeizZi.haveFun(); 


ww 


运行 结 末 如 下 所 示 : 


韩非子 : 开始 吃饭 了 .… 


李斯 :观察 到 韩非子 活动 ， 开 始 向 老板 汇报 了 .… 


李斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 ---> 韩 非 子 在 吃饭 


李斯 ， 汇 报 完毕 


韩非子 : 开始 娱乐 了 .… 


李斯 : 观察 到 韩非子 活动 ， 开 始 向 老板 汇报 了 .… 


李斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 ---> 韩 非 子 在 娱乐 


李斯 : 汇报 完毕 


结 采 出 来 ， 韩 非 子 一 吃 早 瞩 李 斯 束 知 道 ， 韩 非 子 一 娱乐 李斯 也 知 
道 ， 非 常 正确 ! 结 采 正确 但 并 不 表示 你 有 成 绩 ， 我 告诉 你 : 你 的 成 绩 
是 0， 甚 至 古人 负 的 ! 你 有 没有 看 到 你 的 CPU 砚 升 ，Eclipse 不 啊 应 状态 ? 
看 到 了 ? 看 到 了 你 还 不 想 为 什么 ? ! 看 看 上 面 的 程序 ， 别 的 就 不 多 说 
了 ， 使 用 了 一 个 死 循环 while(true) 来 做 监听 ， 要 是 用 到 项 目 中 ， 你 要 多 
少 硬件 投入 进来 ? 你 还 让 不 让 别人 的 程序 运行 了 ? ! 一 台 服 务 器 就 跑 
你 这 一 个 程序 束 完 事 ! 


错误 也 看 到 了 ， 我 们 必须 要 修改 ， 这 个 没 法 应 用 到 项 目 中 ， 而 且 
这 个 程序 根本 就 不 是 面向 对 象 的 程序 ， 这 完全 是 面向 过 程 的 ， 不 改 不 
行 ， 怎么 修改 呢 ? 我 们 来 想 ， 有 既然 韩非子 一 吃饭 李斯 瑟 知 道 了 ， 那 我 
们 为 什么 不 把 李斯 这 个 类 聚集 到 韩非子 那个 类 上 呢 ? 说 改 就 改 ， 立 马 
动手 ,我们 来 看 修改 后 的 类 图 ， 如 图 22-3 所 示 。 


类 图 韭 常 简单 ， 就 是 在 HanFeiZi 类 中 引用 了 LiSi 实 例 ， 看 我 们 程序 
代码 怎么 修改 ，IHanFeiZi 接 口 完全 没有 修改 ， 可 以 参考 代码 清单 22-1 
所 示 。 我 们 来 看 实现 类 的 修改 ， 如 代码 清单 22-7 所 示 。 


代码 清单 22-7 通过 聚集 方式 的 被 观察 者 


public class HanFeiZi implements IHanFeiZif{ 
// 把 李斯 声明 出 来 


private ILiSi liSi =new LiSi(); 


// 韩 非 子 要 吃饭 了 


public void haveBreakfast(){ 


System.out .printlLn(" 韩 非 子 :开始 吃饭 了 ...")) 
// 通 知 李斯 


this.1iSi.update(" 韩 非 子 在 吃饭 " ) ; 


} 

// 韩 非 子 开始 娱乐 了 

public void haveFun(){ 
System.out.println(" 韩 非 子 :开始 娱乐 了 ..."); 
this.1iSsi,update(" 韩 非 子 在 娱乐 ") ) 


被 监控 者 吃饭 、 娱 和 监控 者 获得 需要 信息 后 的 活动 


<<interface>> <<Interftace>> 
IHanFeiZi ILiSi 
| EE | 
| a i 1 1 
+void haveBreakfast() +void update(String context) 


+void haveFun() 


A 


图 22-3 通过 聚集 方式 监控 


韩非子 HanFeiZi 实 现 类 就 把 接口 的 两 个 方法 实现 整 可 以 了 ， 在 每 个 
方法 中 调用 LiSiupdate0) 方 法 ， 完 成 李斯 观察 韩非子 的 职责 ， 李 斯 的 接 
口 和 实现 类 都 没有 任何 改变 ， 请 参考 代码 清单 22-3、22-4。 我 们 再 来 看 
看 Client 程 序 的 变更 ， 如 代码 清单 22-8 所 示 。 


代码 清单 22-8 通过 育 集 方式 的 场景 ; 


public class Client { 
public static void main(String[] args) { 
// 定 义 出 韩非子 


HanFeiZi hanFeiZi = new HanFeizZi(); 
// 然 后 我 们 看 看 韩非子 在 干什么 
hanFeiZzi,haveBreakfast( ) ; 

// 韩 非 子 娱乐 了 


hanFeizZi.haveFun(); 


证 


李斯 殉 不 用 在 场景 类 中 定义 了 ， 非 党 商 单 ， 运 行 结果 相同 ， 不 再 


我 们 思考 一 下 ， 修 改 后 的 程序 运行 结果 正确 ， 效 率 也 比较 高 ， 征 
不 是 应 该 乐 呵 乐 呵 了 ? 大 功 告 成 了 ? 稍 等 等 ， 你 想 在 战国 争 雄 的 时 
候 ， 韩 非 子 这 么 有 人 名望 、 有 实力 的 人 ， 整 只 有 秦 国 关心 他 吗 ? 想 想 也 
不 可 能 呀 ， 确 实 有 一 大 帮 的 各 国 类 似 于 李斯 这 样 的 人 在 看 着 他 ， 监 视 
着 他 的 一 举 一 动 ， 但 是 看 看 我 们 的 程序 ， 你 在 HanFeiZi 这 个 类 中 定义 : 


Private ILiSi liSi =new LiSi(); 


这 样 一 来 只 有 李斯 才能 观察 到 韩非子 ， 这 古 不 对 的 ， 也 束 是 说 韩 
非 子 的 活动 只 通知 了 李斯 一 个 人 ， 这 不 可 能 ， 再 者 说 了 ， 人 李斯 只 观察 
韩非子 的 吃 跑 、 娱 乐 吗 ? 政治 倾 癌 不 关心 吗 ? 思维 倾向 不 关心 吗 ? 杀 
人 放火 不 关心 吗 ? 也 束 说 韩非子 的 一 系列 活动 部 要 通知 李斯 ， 这 可 怎 
么 办 ? 要 按照 上 面 的 例子 ， 我 们 如 何 修改 ? 这 和 开 闭 原则 严重 违背 
呀 ， 我 们 的 程序 有 问题 ， 修 改 如 图 22-4 所 示 。 


| 被 观察 者 自身 活动 


<<imterface>> <<interface>> 
IHanFeiZi Observable 


<<interface>> 
Observer 


tvoid haveBreakfast()| |+void addObserver(Observer observer) a 、 
+void haveFun() +void deleteObserver(Observer observer) vompdate(String: contexd)O 
人 +void notifyObservers(String context) ” : 


Lisi WangSi LiuSi 
| HanFeiZi 


图 22-4 改进 后 的 观察 者 和 被 观察 者 


我 们 把 原 有 类 图 做 了 两 个 修改 : 
e@ 增加 Observable 


实现 该 接口 的 都 是 被 观察 者 ， 那 韩非子 是 被 观察 者 ， 他 当然 也 要 
实现 该 搁 口 了 ， 同 时 他 还 有 与 其 他 良 人 相 弄 的 事 要 做 ， 因 此 他 还 是 要 
实现 IHanFeizi 接 口 。 


e 修改 ILiSI 接 口 名 称 为 Observer 


接口 名 称 修改 了 一 下 ， 这 样 显得 更 抽象 化 ， 所 有 实现 该 接口 的 都 
是 观察 者 (类似 李斯 这 样 的 ) 。 


Observable 是 被 观察 者 ， 束 是 类 似 圩 非 子 这 样 的 人 ， 在 Observable 
接口 中 有 三 个 比较 重要 的 方法 ， 分 别 是 addObserver 增 加 观察 者 ， 
deleteObserver 删 除 观 察 者 ，notifyObservers 通 知 所 有 的 观察 者 ， 这 是 什 


么 意思 呢 ? 我 这 里 有 一 个 信息 ， 一 个 对 象 ， 我 可 以 允许 有 多 个 对 象 来 
察看 ， 你 观察 也 成 ， 我 观察 也 成 ， 只 要 是 观察 者 就 成 ， 也 就 是 说 我 的 
改变 或 动作 执行 ， 会 通知 其 他 的 对 象 ， 看 程序 会 更 明白 一 点 ， 先 看 
Observable 接 口 ， 如 代码 清单 22-9 所 示 。 


代码 清单 22-9 被 观察 者 接口 


public interface Observable { 
// 增 加 一 个 观察 者 
public void addObserver (Observer observer); 
// 删 除 一 个 观察 者 
public void deleteObserver(Observer obSserver ) ; 
// 既 然 要 观察 ， 我 发 生 改 变 了 他 也 应 该 有 所 动作 ， 通 知 观察 者 


public void notifyObservers(String context); 


这 是 一 个 通用 的 被 观察 者 接口 ， 所 有 的 被 观察 者 都 可 以 实现 这 
接口 。 再 来 看 韩非子 的 实现 类 ， 如 代码 清单 22-10 所 示 。 


代码 清单 22-10 被 观察 者 实现 类 


public class HanFeizZi implements Observable ,IHanFeizZif{ 
// 定 义 个 变 长 数组 ， 存 放 所 有 的 观察 者 
private ArrayList<Observer> observerList = new 
ArrayList<Observer>(); 
// 增 加 观察 者 
public void addobserver(0Observer observer)t{ 
this.observerList.add(observer); 


} 

// 删 除 观 察 者 

public void deleteObserver(Observer observer)t{ 
this.observerList.remove(observer); 

} 


// 通 知 所 有 的 观察 者 
public void notifyObservers(String context){ 
for(Observer observer :observerList){ 
observer ,Update(context ) ; 


} 
} 
// 韩 非 子 要 吃饭 了 


public void haveBreakfast(){ 
System.out.println(" 韩 非 子 :开始 吃饭 了 ..."); 
// 通 知 所 有 的 观察 者 
this.,notifyobservers(" 韩 非 子 在 吃饭 " ) ， 


} 

// 韩 非 子 开始 娱乐 了 

public void haveFun(){ 
System.out.println(" 韩 非 子 :开始 娱乐 了 ..."); 
this.,notifyobservers(" 韩 非 子 在 娱乐 " ) ; 


观察 者 只 是 把 原 有 的 ILiSi 接 口 修改 了 一 个 名 字 而 已 ， 如 代码 清单 
22-11 所 示 。 


代码 清单 22-11 观察 者 接口 


public interface Observer { 
// 一 发 现 别人 有 动静 ， 上 自己 也 要 行动 起 来 


public void update(String context ) ， 


然后 是 三 个 很 无 了 的 观察 者 ， 唱 先 看 看 真实 的 李斯 ， 如 代码 清单 
22-12 所 示 。 


代码 清单 22-12 具体 的 观察 者 


public class LiSi implements Observert{ 
// 首 先 李 斯 是 个 观察 者 ， 一 旦 韩非子 有 活动 ， 他 就 知道 ， 他 就 要 向 老板 汇报 
public void update(String Str){ 
System.out .println(" 李 斯 : 观察 到 韩非子 活动 ， 开 始 向 老板 汇 
报 了 3 


this.reportToQinShiHuang(str); 
System,out.println(" 李 斯 : 汇报 完毕 ,,,\n")，; 


} 
// 汇 报 给 秦始皇 


private void reportToQinShiHuang(String reportContext){ 
System,.out .println(" 李 斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 - - 


>"+reportContext ) ; 


} 


李斯 是 真有 其 人 ， 以 下 两 个 观察 者 王 斯 和 刘 斯 是 杜撰 出 来 的 ， 如 
代码 清单 22-13 所 示 。 


代码 清单 22-13 杜撰 的 观察 者 


public class WangSi implements Observert{ 
// 王 斯 ， 看 到 韩非子 有 活动 
public void update(String str)t{ 
System.out.println(" 王 斯 :观察 到 韩非子 活动 ， 自 己 也 开始 活 


动 了 ..."); 
this.cry(str); 
System,.out ,printlLn(" 王 斯 : 哭 死 了 .,..\n"); 


} 
// 一 看 韩非子 有 活动 ， 他 就 痛 殿 
private void cry(String context){ 
System,out.println(" 王 斯 : 因为 "+context+"，- -所 以 我 悲伤 
呀 ! "); 
} 


public class LiuSi implements Observert{ 
// 刘 斯 ， 观 察 到 韩非子 活动 后 ， 上 自己 也 得 做 一 些 事 
public void update(String str)t{ 
System.out.println(" 刘 斯 :观察 到 韩非子 活动 ， 开 始 动 作 


es 


Te 
this.happy(str); 
System.out ,println(" 刘 斯 : 乐 死 了 NAn" ) ， 


} 
// 一 看 韩非子 有 变化 ， 他 就 快乐 
private void happy(String context ){ 
System.out.printLn(" 刘 斯 : 因为 " +context+", - -所 以 我 快 
乐 呀 ! ” ) ; 
} 


} 


所 有 的 历史 人 物 都 在 场 了 ， 那 我 们 来 看 看 这 场 历史 曾 剧 是 如 何 演 
绎 的 ， 如 代码 清单 22-14 所 示 。 


代码 清单 22-14 场景 类 


public class Client { 
public static void main(String[] args) { 


// 三 个 观察 者 产生 出 来 

Observer 1iSi = new LiSi(); 
Observer wangSi = new WangSi(); 
Observer liuSi = new LiuSi(); 

// 定 义 出 韩非子 

HanFeiZi hanFeizZi = new HanFeizZi(); 
// 我 们 后 人 根据 历史 ， 描 述 这 个 场景 ， 有 三 个 人 在 观察 韩非子 
hanFeizi.addObserver(1iSi); 
hanFeizi.addObserver (wangSsi); 
hanFeizZi.addObserver(1iuSsi); 

// 然 后 这 里 我 们 看 看 韩非子 在 干什么 


hanFeizi.haveBreakfast( ) ; 


} 
运行 结果 如 下 所 示 : 
韩非子 ， 开 始 吃饭 了 .… 
李斯 : 观察 到 韩非子 活动 ， 开 始 向 老板 汇报 了 .. 
李斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 -> 韩非子 在 吃饭 
李斯 : 汇报 完毕 .. 
王 斯 ， 观 察 到 韩非子 活动 ， 自 己 也 开始 活动 了 .. 
斯 : 因为 韩非子 在 吃饭 一 所 以 我 悲伤 呀 ! 
FE 斯 ， 回 死 了 .… 
刘 斯 :观察 到 韩非子 活动 ， 开 始 动作 了 .… 
刘 斯 ， 因 为 韩非子 在 吃饭 一 所 以 我 快乐 呀 


刘 斯 : 乐 死 了 


好 了 ， 结 果 也 正确 了 ， 也 符合 开 闭 原则 了 ， 同 时 也 实现 类 间 解 
耘 ， 想 再 加 观察 者 ? 继续 实现 Observer 接口 就 成 了 ， 这 时 候 必 须 修 改 
Client 程 序 ， 因 为 你 的 业务 都 发 生 了 变化 。 这 就 是 观察 者 模式 。 


22.2 观察 者 模式 的 定义 


观察 者 模式 (Observer Pattern) 也 叫做 发 布 订阅 模式 
(Publish/subscribe) , 它 是 一 个 在 项 目 中 经 常 使 用 的 模式 ， 其 定义 如 
下 : 


Define a one-to-many dependency between objects so that when one 
object changes state,all its dependents are notified and updated 
automatically，( 定 义 对 象 间 一 种 一 对 多 的 依赖 天 系 ， 使 得 每 当 一 个 对 象 
改变 状态 ， 则 所 有 依赖 于 它 的 对 象 都 会 得 到 通知 并 被 目 动 更 新 。) 


观察 者 模式 的 通用 类 图 ， 如 图 22-5 所 示 。 


十 Subject 


+Attach(o: Observer) 
+Detach(o: Observer) 
+Notify() 


+Update() 


ConcreteSubject ConcreteObserver 


图 22-5 观察 者 模式 通用 类 图 


我 们 先 来 解释 一 下 观察 者 模式 的 几 个 角色 名 称 : 
e Subject 被 观察 者 


定义 被 观察 者 必须 实现 的 职责 ， 它 必须 能 够 动态 地 增加 、 取 消 观 
2 


察 者 。 它 一 般 是 抽象 类 或 者 是 实现 类 ， 仅 仅 完成 作为 被 观察 者 必须 实 
现 的 职 贡 : 管理 观察 考 并 通知 观察 者 。 


e@ Observer 观 察 者 


观察 者 接收 到 消息 后 ， 即 进行 update (更 新 方法 ， 操作 ， 对 接收 到 
的 信息 进行 处 理 。 


e ConcreteSubject 有 具体 的 被 观察 者 
定义 被 观察 者 目 己 的 业务 逻辑 ， 同 时 定义 对 哪些 事件 进行 通知 。 
e@ ConcreteObserver 具 体 的 观察 者 


每 个 观察 在 接收 到 消息 后 的 处 理 反 应 是 不 同 ， 各 个 观察 者 有 目 己 
的 处 理 逻 辑 。 


各 个 名 词 介绍 完毕， 我 们 来 看 看 各 目的 通用 代码 ， 先 看 被 观察 着 
角色 ， 如 代码 清单 22-15 所 示 。 


代码 清单 22-15 被 观察 者 


public abstract class Subject { 
// 定 义 一 个 观察 者 数组 
private Vector<Observer> obsVector = new Vector<Observer> 
(); 
// 增 加 一 个 观察 者 
public void addObserver (Observer 0){ 
this.obsVector.add(o); 


} 

// 删 除 一 个 观察 者 

public void delobserver(Observer 0){ 
this.obsVector.remove(o); 


} 

// 通 知 所 有 观察 者 

public void notifyObservers()t{ 

for(Observer o:this.obsVvector)t{ 
o.update(); 

} 


被 观察 着 的 职责 非 第 简单， 束 古 定义 谁 能 够 观察 ， 谁 不 能 观察 ， 


程序 中 使 用 ArrayList 和 Vector 没有 太 大 的 差别 ，ArrayList 是 线程 异步 ， 
不 安全 ; Vector 是 线程 同步 ， 安 全 一 就 这 点 区 别 。 我 们 再 来 看 具体 的 


被 观察 者 ， 如 代码 清单 22-16 所 示 。 


代码 清单 22-16 具体 被 观察 者 


public class ConcreteSubject extends Subject { 
// 有 具体 的 业务 
public void doSomething(){ 
/* 


* do something 
*/ 
super .notifyObservers(); 


我 们 现在 看 到 的 是 一 个 纯净 的 观察 者 ， 在 具体 项 目 中 该 类 有 很 多 
的 变种 ， 在 22.4 一 节 中 介绍 。 


我 们 再 来 看 观察 者 角色 ， 如 代码 清单 22-17 所 示 。 


代码 清单 22-17 观察 者 


public interface Observer { 
// 更 新 方法 
public void update( ); 


} 


观察 者 一 般 是 一 个 接口 ， 每 一 个 实现 该 接口 的 实现 类 都 是 具体 观 
察 者 ， 如 代码 清单 22-18 所 示 。 


代码 清单 22-18 具体 观察 者 


public class ConcreteObserver implements Observer { 
// 实 现 更 新 方 》 
public void update() { 
System,out .println(" 接 收 到 信息 ， 并 进行 处 理 !")，; 
} 


那 其 他 模块 是 怎么 来 调用 的 呢 ? 我 们 编写 一 个 Client 类 来 描述 ， 如 
代码 清单 22-19 所 示 。 


代码 清单 22-19 场景 


public class Client { 
public static void main(String[] args) { 

// 创 建 一 个 被 观察 者 
ConcreteSubject subject = new ConcreteSubject(); 
// 定 义 一 个 观察 者 
Observer obs= new ConcreteObserver(); 
// 观 察 者 观察 被 观察 者 
Subject ,addobserver(obs ) ; 
// 观 察 者 开始 活动 了 
Subject .doSomething() ; 


22.3 观察 者 模式 的 应 用 
22.3.1 观 聚 者 模式 的 优点 


e 观察 者 和 被 观察 者 之 则 是 抽象 籼 合 


如 此 设计 ， 则 不 管 是 增加 观察 者 还 是 被 观察 者 都 非常 容易 扩展 ， 
而 且 在 Java 中 都 已 经 实现 的 抽象 层级 的 定义 ， 在 系统 扩展 方面 更 是 得 
心 应 手 。 


e 建立 一 套 触发 机 制 


根据 单一 职责 原则 ， 每 个 类 的 职责 是 单一 的 ， 那 么 怎么 把 各 个 单 
一 的 职 届 串联 成 真实 世界 的 复杂 的 逻辑 关系 呢 ? 比如 ， 我 们 去 打 猜 ， 
打 死 了 一 只 母 应 ， 母 记 有 三 个 幼 媚 ， 因 失去 了 母 廊 而 饼 死 ， 尸 体 又 被 
两 只 殉 座 和 争 抢 ， 因 分 配 不 均 ， 秀 魔 开始 斗 嗓 ， 然 后 最 弱 的 乔 座 死 摊 ， 
生存 下 来 的 乔 座 ， 则 因此 扩大 了 地 盘 .…… 这 束 是 一 个 触发 机 制 ， 形 成 
了 一 个 触发 链 。 观 察 者 模式 可 以 完 类 地 实现 这 里 的 链条 形式 。 


22.3.2 观察 者 模式 的 缺点 


观察 者 模式 需要 考虑 一 下 开发 效率 和 运行 效率 问题 ， 一 个 被 观察 
者 ， 多 个 观察 者 ， 开 发 和 调试 忠 会 比较 复杂 ， 而 且 在 Java 中 消 恩 的 通 
知 默 认 是 顺序 执行 ， 一 个 观察 者 卡 这 ， 会 影响 整体 的 执行 效率 。 在 
种 情况 下 ， 一 般 考 虚 采 用 异步 的 方式 。 


i 


多 级 触发 时 的 效率 更 是 让 人 担忧 ， 大 家 在 设计 时 注意 考虑 。 


22.3.3 观察 者 模式 的 使 用 场景 


e 天 联 行为 场景 。 需 要 注意 的 是 ， 关 联 行 为 是 可 拆 分 的 ， 而 不 
和 是“ 组合” 关系 。 


e 事件 多 级 触发 场景 。 


e 跨 系统 的 消 恩 交换 场景 ， 如 消 乱 队列 的 处 理 机 制 。 


22.3.4 观察 者 模式 的 注意 事项 


使 用 观察 者 模式 也 有 以 下 两 个 重点 问题 要 解决 。 


e 广播 链 的 问题 


如 果 你 做 过 数据 库 的 触发 侨 ， 你 束 应 该 知道 有 一 个 触发 絮 链 的 问 
题 ， 比 如 表 A 上 写 了 一 个 触发 磺 ， 内 容 是 一 个 字段 更 新 后 更 新 表 B 的 一 


条 数据 ， 而 表 B 上 也 有 个 触发 右 ， 要 更 新 表 C， 表 C 也 有 触发 右 .…… 完 
和 蛋 了 ， 这 个 数据 库 基 本 上 了 束 毁 掉 了 ! 我 们 的 观察 者 模式 也 是 一 样 的 问 
题 ， 一 个 观察 者 可 以 有 双重 号 份 ， 既 是 观察 者 ， 也 是 家 观察 者 ， 这 没 
什么 问题 呀 ， 但 是 链 一 旦 建立 ， 这 个 逻辑 环比 较 复 杂 ， 可 维护 性 非常 
靶 ， 根 据 经 验 建 议 ， 在 一 个 观察 者 模式 中 最 多 出 现 一 个 对 象 既 十 观察 
者 也 是 被 观察 者 ， 也 就 是 说 消息 最 多 转发 一 次 (传递 两 次 ) ， 这 还 是 
比较 好 控制 的 。 


注意 “” 它 和 责任 链 模 式 的 最 大 区 别 葡 是 观察 者 广播 链 在 传播 的 过 
程 中 消 筷 是 随时 更 改 的 ， 它 是 由 相 邻 的 两 个 节操 协商 的 消 恩 结构 ， 而 
员 任 链 模式 在 消 恩 传递 过 程 中 基本 上 保持 消 恩 不 可 变 ， 如 有 果 要 改变 ， 
也 只 是 在 原 有 的 消息 上 进行 修正 。 


e 异步 处 理 问 题 


这 个 EJB 是 一 个 非常 好 的 例子 ， 被 观察 者 发 生动 作 了 ， 观 察 者 要 
做 出 回应 ， 如 果 观 察 者 比较 多 ， 而 且 处 理 时 间 比 较 长 怎么 办 ? 那 就 用 
异步 纳 ， 异 步 处 理 就 要 考虑 线程 安全 和 队列 的 问题 ， 这 个 大 家 有 时间 
看 看 Message Queue， 束 会 有 更 深 的 了 解 。 


22.4 观察 者 模式 的 扩展 


22.4.1 Java 世 界 中 的 观察 者 模式 


细心 的 你 可 能 已 经 发 现 ，HanFeiZi 这 个 实现 类 中 应 该 抽象 出 一 个 父 


类 ， 父 类 完全 作为 被 观察 者 的 职责 ， 每 一 个 被 观察 者 只 实现 自己 的 逻 
辑 方法 就 可 以 了 ， 如 此 则 非常 符合 单一 职责 原则 。 是 的 ， 确 实 是 应 该 
这 样 。 幸 运 的 是 ，Java 从 一 开始 诞生 就 提供 了 一 个 可 扩展 的 父 类 ， 即 

java.util.Observable， 这 个 类 就 是 为 那些 “ 容 露 狂 ”* 准 备 的 ， 他 们 老 是 喜 

欢 把 自己 的 状态 变更 让 别人 去 欣赏 ， 去 触发 ， 这 正 符合 了 我 们 现在 的 

要 求 ， 要 把 韩非子 的 所 有 活动 都 暴露 出 去 ， 并 且 想 暴露 给 谁 就 暴露 给 

谁 。 我 们 打开 Java 的 帮助 文件 看 看 ， 查 找 一 下 Observable 是 不 是 已 经 有 
这 个 类 了 ? JDK 中 提供 了 :java.util.Observable 实 现 类 和 java.util.Observer 
接口 ， 也 就 是 说 我 们 上 面 写 的 那个 例子 中 的 Observable 接 口 可 以 改换 成 
java.util.Observale 实 现 类 了 ， 如 图 22-6 所 示 。 


<<interface>> 
java.util.Observer 
+void update(Strmg context)() 


java.util.Observable 


<<interface>> 
IHanFeiZi 


+void haveBreakfast() 
+void haveFun() 


和 


图 22-6 Java 中 的 观察 者 类 图 


是 不 是 又 简单 了 很 多 ? 那 就 对 了 ! 然后 我 们 看 一 下 我 们 程序 的 变 
更 ， 先 看 HanFeiZi 的 实现 类 ， 如 代码 清单 22-20 所 示 。 


代码 清单 22-20 优化 后 的 被 观察 关 


public class HanFeiZi extends Observable,IHanFeizZif{ 
// 韩 非 子 要 吃饭 了 
public void haveBreakfast(){ 
System.out.println(" 韩 非 子 ， 开始 吃饭 了 ..."); 
// 通 知 所 有 的 观察 者 
Super ,SetChanged() ， 
super .notifyobservers(" 韩 非 子 在 吃饭 ") ; 


} 

// 韩 非 子 开始 娱乐 了 

public void haveFun(){ 
System,out,.println(" 韩 非 子 : 开始 娱乐 了 . . .") ; 
Super ,SetChanged() ， 
this.,notifyobservers(" 韩 非 子 在 娱乐 " ) ; 


改变 得 不 多 ， 引 入 了 一 个 java.util.Observable 对 象 ， 删 除了 增加 、 
删除 观察 者 的 方法 ， 人 简单 了 很 多 ， 那 我 们 再 来 看 观察 者 的 实现 类 ， 如 
代码 清单 22-21 所 示 。 


代码 清单 22-21 优化 后 的 观察 者 


public class LiSi implements Observer{ 
// 首 先 李 斯 是 个 观察 者 ， 一 旦 韩非子 有 活动 ， 他 就 知道 ， 他 就 要 向 老板 汇报 
public we update(Observable observable,Object obj ){ 
System.out .println(" 李 斯 : 观察 到 韩非子 活动 ， 开始 向 老板 汇 


报 了 ..."); 
this.reportToQinShiHuang(obj.toString()); 


System.out.println(" 李 斯 : 汇报 完毕 .. .Nn") ， 


// 汇 报 给 秦始皇 
private void reportToQinShiHuang(String reportContext){ 
System.out .println(" 李 斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 --- 


>"+reportContext ) ; 


下 


以 java.util.Observer 接 口 要 求 update 传 递 过 来 两 个 变量 ，Observable 
个 变量 我 们 没 用 到 (接口 中 定义 必须 实现 的 ) ， 束 不 处 理 了 。 其 他 
两 个 观察 者 实现 类 也 是 相同 的 改动 ， 不 再 玖 述 。 


场景 类 没有 改动 ， 运 行 结 采 也 完全 相同 ， 大 家 看 看 我 们 使 用 了 Java 
提供 的 观察 者 模式 后 是 不 是 简单 了 很 多 ， 所 以 在 Java 的 世界 里 横行 时 ， 
多 看 看 API， 有 帮助 很 大 ， 很 多 东西 Java 已 经 帮 你 设计 了 一 个 恨 好 的 杠 


O 〇 


次 


22.4.2 项 目 中 真实 的 观察 者 模式 


为 什么 要 说 “真实 ” 呢 ? 因 为 我 们 刚刚 讲 的 那些 是 太 标 准 的 模式 
了 ， 在 系统 设计 中 会 对 观察 者 模式 进行 改造 或 改 淡 ， 主 要 在 以 下 3 个 方 
面 。 


见 察 者 和 被 观察 者 之 间 的 消息 沟通 


被 观察 者 状态 改变 会 触发 观察 者 的 一 个 行为 ， 同 时 会 传递 一 个 消 
息 给 观察 者 ， 这 是 正确 的 ， 在 实际 中 一 般 的 做 法 是 : 观察 者 中 的 update 
方法 接受 两 个 参数 ， 一 个 是 被 观察 者 ， 一 个 是 DTO (Data Transfer 


Object， 据 传输 对 象 ) ，DTO 一 般 是 一 个 纯洁 的 JavaBean, 由 被 观察 者 生 
成 ， 由 观察 者 消费 。 


当然 ， 如 有 果 考 虑 到 远程 传输 ， 一 般 消 息 是 以 XML 格式 传递 
e 观察 者 响应 方式 


我 们 这 样 来 想 一 个 问题 ， 观 察 痢 羡 一 个 比较 复杂 的 逻辑 ， 它 要 接 
受 被 观察 着 传递 过 来 的 信息 ， 同 时 还 要 对 他 们 进行 逻 往 处 理 ， 在 一 个 
观察 者 多 个 被 观察 者 的 情况 下 ， 性 能 束 需 要 提 到 日 程 上 来 考虑 了 ， 为 
什么 呢 ? 如 采 观 察 者 来 不 及 啊 应 ， 被 观察 者 的 执行 时 间 是 不 古 也 会 被 
拉 长 ? 那 现 在 的 问题 束 是 :观察 者 如 何 快速 啊 应 ? 有 两 个 办 法 : 一 是 
采用 多 线程 技术 ， 走 管 生 被 观察 着 局 动 线程 还 是 观察 考 局 动 线程 ， 都 
可 以 明显 地 提高 系统 性 能 ， 这 也 就 是 大 家 通常 所 说 的 异步 钠 构 ;二 和 是 
缓存 拉 术 ， 有 十 管 你 谁 来 ， 我 已 经 准备 了 足够 的 唤 源 给 你 了 ， 我 你 证 快 
速 啊 应 ， 这 当然 也 是 一 种 比较 好 方案 ， 代 价 就 是 开发 难度 很 大 ， 而 且 
压力 测试 要 做 的 足够 充分 ， 这 种 方案 也 束 古 大 家 说 的 同步 架构 。 


e 侯 观 绎 者 尽量 目 己 做 主 


这 是 什么 意思 呢 ? 被 观察 者 的 状态 改变 是 否 一 定 要 通知 观察 者 
呢 ? 不 一 定 吧 ， 在 设计 的 时 候 要 灵活 考虑 ， 否 则 会 加 重 观察 者 的 处 理 
逻辑 ， 一 般 是 这 样 做 的 ， 对 被 观察 者 的 业务 逻辑 doSomething 方 法 实现 


重 载 ， 如 增加 一 个 doSomething(boolean isNotifyObs) 方 法 ， 决 定 是 否 通 
知 观察 者 ， 而 不 是 在 消息 到 达观 察 者 时 才 判 断 是 否 要 消费 。 


22.4.3 订阅 发 布 模型 


观察 者 模式 也 叫做 发 布 /订阅 模型 (Publish/Subscribe) ， 如 果 你 做 
过 EJB (Enterprise JavaBean) 的 开发 ， 这 个 你 绝对 不 会 陌生 。EJB2 是 
个 折腾 死人 不 偿命 的 玩意 儿 ， 写 个 Bean 要 实现 ， 还 要 继承 ， 再 加 上 那 
一 堆 的 配置 文件 ， 小 项 目 还 竣 合 ， 你 要 知道 用 EJB 开 发 的 基本 上 都 不 是 
小 项 目 ， 到 最 后 是 每 个 项 目 成 员 都 在 驾 EJB 这 个 忽悠 人 的 东西 ; 但 是 
EJB3 是 个 非常 优秀 的 框架 ， 还 是 算 比 较 轻 量 级 ， 写 个 Bean 只 要 加 个 
Annotaion 就 成 了 ， 配 置 文件 减少 了 ， 而 且 也 引入 了 依赖 注入 的 概念 ， 
虽然 只 是 EJB2 的 翻版 ,但 是 毕竟 还 是 前 进 了 一 步 。 在 EJB 中 有 3 个 类 型 


的 Bean: Session Bean、Entity Bean 和 MessageDriven Bean， 我 们 这 里 来 


说 一 下 MessageDriven Bean (一 般 简 称 为 MDB) ， 消 息 驱 动 Bean， 消 
息 的 发 布 者 (Provider) 发 布 一 个 消息 ， 也 就 是 一 个 消息 驱动 Bean， 通 
过 EJB 容 器 (一 般 是 Message Queue 消 息 队 列 ) 通知 订阅 者 做 出 回应 ， 
从 原理 上 看 很 位 单 ， 就 是 观察 者 模式 的 升级 版 ， 或 者 说 是 观察 则 模式 
的 BOSS 版 。 


22.5 最 佳 实践 


观察 者 模式 在 实际 项 目 和 生活 中 非常 彰 见 ， 我 们 举 几 个 经 常 发 生 
的 例子 来 说 明 。 


e 文件 系统 
比如 ， 在 一 个 目录 下 新 建立 一 个 文件 ， 这 个 动作 会 同时 通知 目 永 


管理 如 增加 该 目录 ， 并 通知 磁盘 管理 右 减 少 1KB 的 空间 ， 也 束 说 “ 文 
件 ?” 是 一 个 被 观察 者 ,“ 目 孙 管 理 硕 ”和 “磁盘 管理 器” 则 是 观察 者 。 


e 狂 好 游戏 


夜里 猫 叫 一 声 ， 家 里 的 老鼠 撒 腿 丈 跑 ， 同 时 也 吵 醒 了 熟睡 的 主 
人 ， 这 个 场景 中 ,，“ 猫 ” 束 是 被 观察 者 ， 老 鼠 和 人 则 是 观察 者 。 


e ATM 取 钱 


比如 你 到 ATM 机 器 上 取 钱 ， 多 次 输 错 密 码 ， 卡 束 会 被 ATM 理 挥 ， 
否 卡 动作 发 生 的 时 候 ， 会 触发 哪些 事件 呢 ? 第 一 ， 摄 像 头 连续 快 拍 ， 
第 二 ， 通 知 监控 系统 ， 吞 卡 发 生 ; 第 三 ， 初 始 化 ATM 机 屏幕 ， 返 回 最 
初 状态 。 一 般 前 两 个 动作 都 是 通过 观察 者 模式 来 完成 的 ， 后 一 个 动作 


征 异 各 来 完成 。 


e 播 收 音 机 


电台 在 广播 ， 你 可 以 打开 一 个 收音 机 ， 或 者 两 个 收音 机 来 收听 ， 
电台 就 古 被 观察 者 ， 收 首 机 束 古 观察 者 。 


第 23 章 ”门面 模式 


23.1 我 要 投 闻 信 件 


我 们 都 写 过 纸 质 信件 吧 ， 比 如 给 女 朋 友 写 情书 什么 的 。 写 信 的 过 
程 大 家 应 该 都 还 记得 一 一 先 写 信 的 内 容 ， 然 后 写 信 封 ， 再 把 信 放 到 信 
封 中 ， 封 好 ， 投 递 到 信箱 中 进行 邮递 ， 这 个 过 程 还 是 比较 简单 的 ， 虽 
然 简单 ， 但 是 这 4 个 步骤 都 不 可 或 缺 ! 我 们 先 把 这 个 过 程 通过 程序 实现 
出 来 ， 如 图 23-1 所 示 。 


<<interface>> 
ILetterProcess 


+Vold writeContext(Strmg context) 


| 

| +void filEnvelope(Strng address) 
Hvoid letterInotoEnvelope() 
+void sendLetter() 


LetterProcessImpl 
| 
| | 


i 二 区 
写 信 过 程 的 具体 实现 


图 23-1 写 信 过 程 类 图 


这 一 个 过 程 还 是 比较 简单 的 ， 我 们 看 程序 的 实现 ， 先 看 接口 ， 如 
代码 清单 23-1 所 示 。 


代码 清单 23-1 写 信 过 程 接口 


public interface ILetterProcess { 
// 首 先 要 写 信 的 内 容 
public void writeContext(String context ) ， 
// 其 次 写 信封 
public void fillEnvelope(String address); 


// 把 信 放 到 信封 里 
public void letterIinotoEnvelope( ); 
// 然 后 邮递 

public void sendLetter(); 


在 接口 中 定义 了 完成 的 一 个 写 信 过 程 ， 这 个 过 程 需 要 实现 ， 其 实 
现 类 如 代码 清单 23-2 所 示 。 


代码 清单 23-2 写 信 过 程 的 实现 


public class LetterProcessImpl implements ILetterProcess { 


// 写 信 
public void writeContext(String context) { 

System.out .println(" 填 写 信 的 内 容 ..." + context); 
} 


// 在 信 封 上 二 与 / 必要 的 信 , /人心 \ 
public void fillEnvelope(String address) { 
System.out.println(" 填 写 收 件 人 地 址 及 姓名 ..." + 


address ); 


// 把 信 放 到 信封 中 ， 并 封 好 

public void letterIinotoEnvelope() { 
System.out.println(" 把 信 放 到 信封 中 ..."); 

} 


// 塞 到 邮箱 中 ， 邮 递 
public void sendLetter() { 

System.out .println(" 邮 递 信 件 ,.."); 
} 


在 这 种 环境 下 ， 最 宗 的 是 写 信人 ， 为 了 发 送 一 封 信 要 有 4 个 步 又 
而 且 这 4 个 步骤 还 不 能 颠倒 ， 我 们 爷 看 看 这 个 过 程 如 何 通过 程序 表现 出 
来 ， 有 人 开始 用 这 个 过 程 写 信 了 ， 如 代码 清单 23-3 所 示 。 


代码 清单 23-3 场景 


public class Client { 
public static void main(String[] args) { 
// 创 建 一 个 处 理 信件 的 过 程 
ILetterpProcess letterProcess = new 
LetterProcessImpl(); 
// 开 始 写 信 
letterProcess. i Tt， 'S me, do you 
know who I am? I'm your old lover. I'd like to. ; 
// 开 始 写 信 封 
letterProcess.fillEnvelope("Happy Road No. 666,God 
Province, Heaven"); 
// 把 信 放 到 信封 里 ， 并 封装 好 
letterProcess.letterIinotoEnvelope(); 
// 跑 到 邮局 把 信和 塞 到 邮箱 ， 投 弟 
letterProcess.sendLetter(); 


如 


me 


一 


运行 结果 如 下 所 示 : 


填写 信 的 内 容 ...Hello,It's me,do you know who I am? Im your old lover. Pd like to... 


填写 收 件 人 地 址 及 姓名 ...Happy Road No. 666,God Province,Heaven 


把 信 放 到 信封 


邮递 信件 .… 


我 们 回 过 头 来 看 看 这 个 过 程 ， 它 与 高 内 聚 的 要 求 相差 其 远 ， 更 不 
要 说 迪 米 特 法 则 、 接口 隔离 原则 了 “。 你 想 想 ， 你 要 知道 这 4 个 步 又， 而 
且 还 要 知道 它们 的 顺序 ， 一 旦 出 错 ， 信 就 不 可 能 邮寄 出 去 ， 这 在 面向 
对 象 的 编程 中 是 极 度 地 不 适合 ， 它 根本 就 没有 完成 一 个 类 所 具有 的 单 
一 职责 。 


还 有 ， 如 采信 件 多 了 束 非 常 麻烦 ， 每 封 信 都 要 这 样 运转 一 过， 非 
得 素 死 ， 更 别 说 要 发 个 广告 信 了 ， 那 去 么 办 呢 ? 还 好 ， 现 在 邮局 开发 


了 一 个 新 业务 ， 你 只 要 把 信件 的 必要 信息 告诉 我 ， 我 给 你 发 ， 我 来 完 
成 这 4 个 过 程 ， 只 要 把 信件 交 给 我 吏 成 了 ， 其 他 融 不 要 管 了 。 非 党 好 的 
方案 ! 我 们 来 看 类 图 ， 如 图 23-2 所 示 。 


写 信 的 过 程 


<<interface>> 
ILetterProcess 


ModenPostOffice 


tvoid writeContext(Strng context) 
+void fillEnvelope(Strmg address) 
+void letterInotoEnvelope() 

+void sendLetter() 


. 现代 化 的 邮局 ~ 
LetterProcessImpl 


-ILetterProcess letterProcess 


+vold sendLetter(String context, String address) 


图 23-2 增加 现代 化 邮局 的 类 图 


这 还 是 比较 人 简单 的 类 图 ， 增 加 了 一 个 ModenPostOffice 类 ， 仙 和 贡 对 
一 个 比较 复杂 的 信件 处 理 过 程 的 封 狼 ， 然 后 高 层 模 块 只 要 和 它 有 交互 
束 成 了 ， 如 代码 清单 23-4 所 示 。 


代码 清单 23-4 现代 化 邮局 


public class ModenPostoffice { 
private ILetterProcess letterProcess = new 
LetterProcessImpl( ); 


// 写 信 ， 封装， 投递 ， 一 体 化 

public void sendLetter(String context,String address){ 
// 帮 你 写 信 
JetterProcess ,writeCcontext(context ) ; 
// 写 好 信封 
letterProcess.fillEnvelope(address); 
// 把 信 放 到 信封 中 
letterProcess.letterIinotoEnvelope!(); 
// 邮 递 信件 
letterPprocess.sendLetter(); 


这 个 类 是 什么 意思 呢 ， 就 是 说 现在 有 一 个 Hell Road PostOffice (地 
狱 路 邮局 ) 提供 了 一 种 新 型 服务 ， 客 户 只 要 把 信 的 内 容 以 及 收 信 地 址 
给 他 们 ， 他 们 吏 会 把 信 写 好 ， 封 好 ， 并 发 送出 去 。 这 种 服务 推出 后 大 
受 欢 迎 ， 这 多 人 简单， 客户 减少 了 很 多 工作 ， 谁 不 乐意 呀 。 那 我 们 看 看 
客户 是 怎么 调用 的 ， 如 代码 清单 23-5 所 示 。 


代码 清单 23-5 场景 


public class Client { 
public static void main(String[] args) { 

// 现 代 化 的 邮局 ， 有 这 项 服务 ， 邮 局 名 称 叫 HeL1L Road 
ModenPostoffice hellRoadPostOffice = new 

ModenPostoffice( ); 
// 你 只 要 把 信 的 内 容 和 收 信人 地 址 给 他 ， 他 会 帮 你 完成 一 系列 的 工作 
// 定 义 一 个 地 址 
String address = "Happy Road No. 666, God 

Province, Heaven",; 


// 信 的 内 容 

String context = "Hello,It's me,do you know who I 
am? I'm your old lover. I'd like to...."; 

// 你 给 我 发 送 吧 


hellRoadPostOffice.sendLetter(context, address); 


一 一 


运行 结 琳 是 相同 的 。 我 们 看 看 场景 类 是 不 古人 简化 了 很 多 ， 只 要 与 
ModenPostOffice 交 互 吏 成 了 ， 其 他 的 什么 都 不 用 管 ， 写 信封 啦 、 写 地 
址 啦 .……. 都 不 用 关心 ， 只 要 把 需要 的 信息 提交 过 去 就 成 ， 邮 局 保证 
会 按照 我 们 指定 的 地 址 把 指定 的 内 容 发 送出 去 ， 这 种 方式 不 仅 简 单 ， 
而 且 扩 展 性 还 非常 好 ， 比 如 一 个 非常 时 期 ， 寄 往 God Province 《上 帝 
省 ) 的 邮件 都 必须 进行 安全 检查 ， 那 我 们 就 很 好 处 理 了 ， 如 图 23-3 所 


修 ° 


ER 
| 
<<interface>> 
lLetterProcess 
ModenPostOffice 


+void writeContext(String context) 
+void fillEnvelope(String address) 
+void letterInotoEnvelope() 

+void sendLetter() 


-I[LetterProcess letterProcess 
-Police letterPolice 


Hvoid sendLetter(String context, Strmg address) 


| 


LetterProcessImpl | Police 
| -Police letterPolice 
| | 


+vold checkLetter(ILetterProcess letterProcess) 


图 23-3 扩展 后 的 系统 类 图 


增加 了 一 个 Police 类 ， 人 负责 对 信件 进行 检查 ， 如 代码 清单 23-6 所 


修 ° 


代码 清单 23-6 信件 检查 类 


public class Police { 
// 检 查 信件 ， 检 查 完毕 后 警察 在 信封 上 盖 个 稚 : 此 信 无 病毒 
public void de letterPprocess)t{ 
System,.out .println(letterProcess+" 信件 已 经 检查 过 
St 
} 


我 们 再 来 看 一 下 封装 类 ModenPostOffice 的 变更 ， 它 封装 了 这 部 分 
的 变化 ， 如 代码 清单 23-7 所 示 。 


代码 清单 23-7 扩展 后 的 现代 化 邮局 


public class ModenPostOffice { 
private ILetterProcess letterProcess = new 
LetterProcessImpl(); 
private Police letterPolice = new Police(); 
// 写 信 ， 封 装 ， 投 递 ， 一 体 化 了 
public void sendLetter(String context,String address){ 
// 帮 你 写 信 
letterProcess.writeContext(context); 
// 写 好 信封 
letterProcess.fillEnvelope(address); 
// 警 察 要 检查 信件 
letterPolice.checkLetter(letterProcess); 
// 把 信 放 到 信封 中 
JetterProcess, letterInotoEnveJlope() ; 
// 邮 递 信件 
JetterProcess.SendLetter(); 


只 是 增加 了 一 个 letterPolice 变 量 的 声明 以 及 一 个 方法 的 调用 ， 那 这 
个 写 信 有 的 过 程 束 变 成 这 样 ， 先 写 信 、 写 信封 ， 然 后 警察 开始 检查 ， 之 
后 才 把 信 放 到 信封 ， 最 后 发 送出 去 ， 那 这 个 变更 对 客户 来 说 是 透明 

的 ， 他 根本 就 看 不 到 有 人 在 检查 他 的 邮件 ， 他 也 不 用 了 解 ， 反 正 现 代 
化 的 邮件 系统 都 帮 他 做 了 ， 这 也 和 是 他 乐意 的 地 方 。 


场景 类 还 古 完 全 相同 ， 但 是 运行 结 末 稍 有 不 同 ， 如 下 所 示 : 


填写 信 的 内 容 ...Hello,It's me,do you know who I am?Im your old lover.I'd like to... 


填写 收 件 人 地 址 及 姓名 ...Happy Road No.666,God Province,Heaven 


com.cbf4life.common3.LetterProcessImpl@15ff48b 信件 已 经 检查 过 了 .. 


把 信 放 到 信封 


邮递 信件 .… 


高 层 模块 没有 任何 改动 ， 但 是 信件 却 已 经 被 检查 过 了 “。 这 正 是 我 
们 设计 所 需要 的 模式 ， 不 改变 子 系统 对 外 上 暴露 的 接口 、 方 法 ， 只 改变 
内 部 的 处 理 逻 辑 ， 其 他 兄弟 模块 的 调用 产生 了 不 同 的 结果 ， 确 实 古 一 
个 非常 棒 的 设计 。 这 束 是 门面 模式 。 


23.2 | 面 模式 的 定义 


门面 模式 (Facade Pattern) 也 叫做 外 观 模 式 ， 是 一 种 比较 常用 的 
封 状 模式， 其 定义 如 下 : 


Provide a unified interface to a set of interfaces in a subsystem.Facade 
defines a higher-level interface that makes the subsystem easier to use. (要 
求 一 个 子 系统 的 外 部 与 其 内 部 的 通信 必须 通过 一 个 统一 的 对 象 进行 。 
门面 模式 提供 一 个 高 层次 的 接口 ， 使 得 子 系统 更 易于 使 用 。) 


门面 模式 注重 “统一 的 对 象 ”， 也 就 是 提供 一 个 访问 子 系统 的 接 
口 ， 除 了 这 个 接口 不 允许 有 任何 访问 子 系统 的 行为 发 生 ， 其 通用 类 
图 ， 如 图 23-4 所 示 。 


二 


Subsystem Classes 
一 
< 人. 人 人 


图 23-4 扩展 后 的 系统 类 图 


是 的 ， 类 图 就 这 么 简单 ， 但 是 它 代 表 的 意义 可 是 异常 复杂 ， 
Subsystem Classes 是 子 系统 所 有 类 的 倘 称 ， 它 可 能 代表 一 个 类 ， 也 可 能 
代表 几 十 个 对 象 的 集合 。 表 管 多 少 对 象 ， 我 们 把 这 些 对 象 全 部 圈 入 子 
系统 的 范畴 ， 其 结构 如 图 23-5 所 示 。 


Facade 


于 系统 


图 23-5 门面 模式 示意 图 


再 简单 地 说 ， 门 面 对 象 是 外 界 访问 子 系统 内 部 的 唯一 通道 ， 不 管 
子 系统 内 部 是 多 么 杂乱 无 章 ， 只 要 有 门面 对 象 在 ， 殊 可 以 做 到 “金玉 其 
外 ， 败 系 其 中 ”。 我 们 移 明 确 一 下 门面 模式 的 角色 。 


e Facade 门 面 角色 


客户 端 可 以 调用 这 个 角色 的 方法 。 此 角色 知晓 子 系统 的 所 有 功能 
和 责任 。 一 般 情 况 下 ， 本 角色 会 将 所 有 从 客户 端 发 来 的 请 求 委派 到 相 
应 的 于 系统 去 ， 也 束 说 该 角色 没有 实际 的 业务 逻辑 ， 只 是 一 个 委托 
Rs 


e@ subsystem 子 系统 角色 


可 以 同时 有 一 个 或 者 多 个 子 系统 。 每 一 个 于 系统 都 不 是 一 个 单独 
的 类 ， 而 是 一 个 类 的 集合 。 子 系统 并 不 知道 门面 的 存在 。 对 于 子 系统 
而 言 ， 门 面 仅 仅 是 另外 一 个 客户 端 而 已 。 


我 们 来 看 一 下 门面 模式 的 通用 源码 ， 先 来 看 子 系统 源 代码 。 由 于 
子 系统 是 类 的 集合 ， 因 此 要 描述 该 集合 很 花费 精力 ， 每 一 个 子 系统 都 
不 相同 ， 我 们 使 用 3 个 相互 无 关 的 类 来 代表 ， 如 代码 清单 23-8 所 示 。 


代码 清单 23-8 子 系统 


public class ClassA 
public void doSomethingA(){ 
// 业 务 逻辑 
} 
public class ClassB { 
public void doSomethingB(){ 
// 业 务 逻 辑 
} 
public class ClasscC { 


public void doSomethingcC(){ 
// 业 务 逻 辑 


我 们 认为 这 3 个 类 属于 近邻 ， 处 理 相 关 的 业务 ， 因 此 应 该 被 认为 是 
一 个 子 系统 的 不 同 逻 辑 处 理 模 块 ， 对 于 此 子 系统 的 访问 需要 通过 门面 
进行 ， 如 代码 清单 23-9 所 示 。 


代码 清单 23-9 门面 对 象 


public class Facade { 

// 被 委托 的 对 象 

private ClassA a = new ClassA(); 

private ClassB b = new ClassB(); 

private ClassC c = new ClasscC(); 

// 提 供给 外 部 访问 的 方法 

public void methodA(){ 
this.a.doSomethingA( ); 

} 


public void methodB(){ 
this.b.doSomethingB(); 
} 


public void methodc(){ 
this.c.doSomethingC(); 
} 


23.3 门面 模式 的 应 用 
23.3.1 门面 模式 的 优点 


门面 模式 有 如 下 优点 。 


e 减少 系统 的 相互 依赖 


想 想 看 ， 如 有 果 我 们 不 使 用 门面 模式 ， 外 界 访 问 直接 深入 到 子 系统 
内 部 ， 相 互 之 间 是 一 种 强 糊 合 天 系 ， 你 死 我 束 死 ， 你 活 我 才能 活 ， 这 
样 的 强 依 赖 是 系统 设计 所 不 能 接受 的 ,1] 面 模式 的 出 现 束 很 好 地 解决 
了 该 问题 ， 所 有 的 依赖 都 是 对 门面 对 象 的 依赖 ， 与 子 系统 无 天 。 


依赖 减少 了 ， 灵 活性 目 然 提高 了 。 不 管子 系统 内 部 如 何 变化 ， 只 
要 不 影响 到 门面 对 象 ， 任 你 目 由 活动 。 


e 提 噩 安全 性 


想 让 你 访问 子 系统 的 哪些 业务 束 开 通 哪 些 逻 辑 ， 不 在 | ] 面 上 开通 
的 方法 ， 你 休想 访问 到 。 


23.3.2 门面 模式 的 缺点 


门面 模式 最 大 的 缺点 束 是 不 符合 开 财 原则 ， 对 修改 关闭 ， 对 扩展 
开放 ， 看 看 我 们 那个 门面 对 象 吧 ， 它 可 是 重 中 之 重 ， 一 旦 在 系统 投产 
后 发 现 有 一 个 小 错误 ， 你 怎么 解决 ? 完全 遵从 开 闭 原则 ， 根 本 没 办 法 
解决 。 继 承 ? 覆 写 ? 都 顶 不 上 用 ， 唯 一 能 做 的 一 件 事 就 是 修改 门面 角 
色 的 代码 ， 这 个 风险 相当 大 ， 这 束 需 要 大 家 在 设计 的 时 候 慎之 又 慎 ， 
多 思考 几 裔 才 会 有 好 收获 。 


23.3.3 门面 模式 的 使 用 场景 


e 为 一 个 复杂 的 模块 或 子 系统 提供 一 个 供 外 界 访问 的 接口 


e 于 系统 相对 独立 一 一 外 界 对 子 系统 的 访问 只 要 黑箱 操作 即 可 


比如 利 妃 的 计算 问题 ， 没 有 次 厚 的 业务 知识 和 扎实 的 技术 水 平 羡 
不 可 能 开发 出 该 子 系统 的 ， 但 是 对 于 使 用 该 系统 的 开发 人 员 来 说 ， 他 
需要 做 的 丈 是 输入 金额 以 及 存 期 ， 其 他 的 都 不 用 关心 ， 返 回 的 结 末 束 
征 利 妃 ， 这 时 候 ， 门 面 模式 是 非 使 用 不 可 了 。 


e 预防 低 水 平 人 员 融 来 的 风险 扩散 


比如 一 个 低 水 乎 的 技术 人 员 参 与 项 目 开发 ， 为 降低 个 人 代码 质量 
对 整体 项 目的 影响 风险 ， 一 般 的 做 法 是 “ 画 地 为 牢 ”， 只 能 在 指定 的 子 


系统 中 开发 ， 然 后 再 提供 门面 接口 进行 访问 操作 。 


23.4「] 面 模式 的 注意 事项 
23.4.1 一 个 子 系统 可 以 有 多 个 门面 


一 般 情 况 下 ， 一 个 子 系统 只 要 有 一 个 门面 足够 了 ， 在 什么 情况 下 
一 个 子 系统 有 多 个 门面 呢 ? 以 下 列举 了 几 个 。 


e 1] 面 已 经 庞大 到 不 能 妨 受 的 程度 


比如 一 个 纯洁 的 门面 对 象 已 经 超过 了 200 行 的 代码 ， 虽 然 都 是 非常 
简单 的 委托 操作 ， 也 建议 拆 分 成 多 个 门面 ， 人 否则 会 给 以 后 的 维护 和 扩 
展 市 来 不 必要 的 麻烦 。 那 怎么 拆 分 呢 ? 按照 功能 拆 分 征 一 个 非常 好 的 
原则 ， 比 如 一 个 数据 库 操作 的 门面 可 以 拆 分 为 得 询 门 面 、 删 除 门面 、 
更 新 门面 等 。 


e 于 系统 可 以 提供 不 同 访问 路 径 


我 们 以 门面 模式 的 通用 产 代码 为 例 。ClassA、ClassB、ClassC 是 
一 个 了 手 系 统 的 中 3 个 对 象 ， 现 在 有 两 个 不 同 的 高 层 模块 来 访问 该 子 系 
统 ， 模 块 一 可 以 完整 的 访问 所 有 业务 逻辑 ， 也 束 是 通用 代码 中 的 
Facade 类 ， 它 是 于 系统 的 信任 模块 ， 而 模块 二 属于 受 限 访 问 对 象 ， 只 
能 访问 methodB 方 法 ， 那 该 如 何 处 理 呢 ? 在 这 种 情况 下 ， 整 需要 建立 


两 个 门面 以 供 不 同 的 高 层 模块 来 访问 ， 在 原 有 的 通用 源码 上 增加 一 个 
新 的 门面 即 可 ， 如 代码 清单 23-10 所 示 。 


代码 清单 23-10 新 增 门 面 


public class Facade2 { 
// 引 用 原 有 的 门面 
private Facade facade = new Facade(); 
// 对 外 提供 唯一 的 访问 子 系统 的 方法 
public void methodB( ){ 
this.facade.methodB( ); 
} 


增加 的 门面 非常 人 滑 单 ， 委 托 给 了 已 经 存在 的 门面 对 象 Facade 进 行 
处 理 ， 为 什么 要 使 用 委托 而 不 再 编写 一 个 委托 到 子 系统 的 方法 呢 ? 那 
征 因 为 在 面 问 对 象 的 编程 中 ， 尽 量 保持 相同 的 代码 只 编写 一 志 ， 如 免 
以 后 到 处 修改 相似 代码 的 悲剧 。 


23.4.2 门面 不 参与 子 系统 内 的 业务 逻辑 


我 们 这 节 的 标题 是 什么 意思 呢 ? 我 们 举 一 个 例子 来 说 明 ， 还 是 以 
通用 源 代码 为 例 。 我 们 把 门面 上 的 methodC 上 的 逻辑 修改 一 下 ， 它 必 
须 先 调用 ClassA 的 doSomethingA 方 法 ， 然 后 再 调用 ClassC 的 
doSomethingC 方 法 ， 如 代码 清单 23-11 所 示 。 


代码 清单 23-11 修改 门面 


public class Facade { 
// 被 委托 的 对 象 
private ClassA a = new ClassA(); 
private ClassB b = new ClassB(); 
private ClassC c = new ClassC(); 
// 提 供给 外 部 访问 的 方法 
public void methodA(){ 

this.a.doSomethingA( ); 

} 


public void methodB(){ 
this.b.doSsomethingB( ); 
} 


public void methodCc(){ 
this.a.doSomethingA( ); 
this.c.doSomethingC( ); 


还 是 非常 簿 单 ， 只 是 在 methodC 方 法 中 增加 了 doSomethingA( 方 法 
的 调用 ， 可 以 这 样 做 吗 ? 我 相信 大 部 分 读者 都 说 可 以 这 样 做 ， 而 且 已 
经 在 实际 系统 开发 中 这 样 使 用 了 ， 我 今天 告诉 各 位 ， 这 样 设计 十 非常 
不 靠 谱 的 ， 为 什么 呢 ? 因为 你 已 经 让 门面 对 象 参 与 了 业务 逻辑 ， 门 ] 面 
对 象 只 是 提供 一 个 访问 子 系统 的 一 个 路 径 而 已 ， 它 不 应 该 也 不 能 参与 
具体 的 业务 逻辑 ， 否 则 就 会 产生 一 个 倒 依 赖 的 问题 ， 子 系统 必须 依赖 
门面 才能 被 访问 ， 这 是 设计 上 一 个 严重 错误 ， 不 仅 违 反 了 单一 职责 原 
则 ， 同 时 也 破坏 了 系统 的 封 洲 性 。 


说 了 这 么 多 ， 那 对 于 这 种 情况 该 怎么 处 理 呢 ? 建立 一 个 封装 类 ， 
封装 完毕 后 提供 给 门面 对 象 。 我 们 移 建立 一 个 封装 类 ， 如 代码 清单 23- 
12 所 示 。 


代码 清单 23-12 封装 类 


public class Context { 
// 委 托 处 理 
private ClassA a 
private ClassC c 
// 复 杂 有 的 计算 
public void complexMethod(){ 
this.a.doSomethingA( ); 
this.c.doSomethingC( ); 


new ClassA( ); 
new Classc(); 


该 封装 类 的 作用 束 是 产生 一 个 业务 规则 complexMethod， 并 且 写 
的 生存 环境 是 在 子 系统 内 ， 仅 仅 依 赖 两 个 相关 的 对 象 ， 门 面 对 象 通过 
对 它 的 访问 完成 一 个 复杂 的 业务 逻辑 ， 如 代码 清单 23-13 所 示 。 


代码 清单 23-13 门面 类 


public class Facade { 
// 被 委托 的 对 象 
private ClassA a = new ClassA(); 
private ClassB b = new ClassB(); 
private Context context = new Context(); 
// 提 供给 外 部 访问 的 方法 
public void methodA(){ 
this.a.doSomethingA( ); 
上 


public void methodB(){ 
this.b.doSsomethingB( ); 
} 


public void methodc()t{ 
this.context.complexMethod( ); 
} 


通过 这 样 一 次 封闭 后 ， 门 面 对 象 又 不 参与 业务 逻辑 了 ， 在 门面 模 
式 中， 门面 角色 应 该 是 稳定 ， 它 不 应 该 经 常 变 化， 一 个 系统 一 旦 投入 
运行 它 就 不 应 该 被 改变 ， 它 是 一 个 系统 对 外 的 接口 ， 你 变 来 变 去 还 您 
么 你 证 其 他 模块 的 稳定 运行 呢 ? 但 是 逻辑 是 会 经 党 变化 的 ， 我 
们 已 经 把 它 的 变化 封装 在 子 系统 内 部 ， 无 论 你 如 何 变化 ， 对 外 界 的 访 
问 者 来 说 ， 都 还 是 同一 个 门面 ， 同 样 的 方法 一 一 这 才 古 染 构 师 最 希望 
看 到 的 结构 。 


23.5 最 佳 实践 


门面 模式 是 一 个 很 好 的 封 逆 方法 ， 一 个 子 系统 比较 复杂 时 ， 比 如 
算法 或 者 业务 比较 复杂 ， 束 可 以 封 泛 出 一 个 或 多 个 门面 出 来 ， 项 目的 
结构 们 单 ， 而 且 扩 展 性 非常 好 。 还 有 ， 对 于 一 个 较 大 项 目 ， 为 了 避免 
人 员 融 来 的 风险 ， 也 可 以 使 用 门面 模式 ， 技 术 水 平 比较 蕾 的 成 员 ， 尽 
量 安排 独立 的 模块 ， 然 后 把 他 写 的 程序 封装 到 一 个 门面 里 ， 尽 量 让 其 
他 项 目 成 员 不 用 看 到 这 些 人 的 代码 ， 看 也 看 不 履 ， 我 也 中 到 过 一 个 “高 
人 ” 写 的 代码 ，private 方 法 、 构 造 画 数 、 常 量 基本 都 不 用 ， 你 要 一 个 
public 方 法 ， 好 ， 一 个 类 里 束 一 个 public 方 法 ， 所 有 代码 都 在 里 面 ， 然 
后 你 殉 看 吧 ， 一 大 坨 程序 ， 看 着 束 能 把 人 通 饮 。 使 用 门面 模式 后 ， 对 
门面 进行 单元 测试 ， 约 束 项 目 成 员 的 代码 质量 ， 对 项 目 整体 质量 的 提 
升 也 是 一 个 比较 好 的 帮助 。 


第 24 章 ” 备 护 如 模式 


24.1 如 此 人 乙女 孩子 ， 你 还 不 乐 


大 家 有 没有 看 过 尼古拉斯 凯 奇 主演 的 《Next》 (中 文 译名 为 《 预 
见 未 来 》) ? 尼古拉斯 凯 奇 饰演 一 个 可 以 预 视 并 且 扭 转 未 来 的 人 ， 其 
中 有 一 个 情节 很 是 让 人 心动 一 一 男 文 主角 见面 的 那 段 情 万 : Cris 
Johnson (尼古拉斯 凯 奇 饰演 ) 坐 在 咖啡 吧台 前 ， 看 着 离 目 己 近 在 点 尺 
的 Callie Ferris ( 朱 莉 安 .摩尔 饰演 ) ， 计 划 着 怎么 认识 这 个 命中 注定 的 
女人 ， 看 Cris Johnson 如 何 利用 目 己 的 特异 功能 : 


e Cris Johnson 端 着 一 杯 咖啡 走 过 去 ， 说 “你 好 ， 可 以 认识 你 
吗 ? ”被 拒绝 ， 恢 复 到 坐 在 咖啡 吧台 前 的 状态 。 


e 走 过 去 询问 是 否 可 以 搭车 ， 被 拒绝 ， 恢 复原 状 。 


e 帮助 解决 困境 ， 被 拒绝 ， 恢 复原 状 。 


e 采用 嬉 皮 士 的 方式 解决 困境 ， 刻 拒绝 ， 恢 复原 状 。 


e 帮助 解决 困境 ， 被 打 伤 ， 装 可 怜 ，Callie Ferris 怜 惜 ， 于 是 乎 相识 


看 看 这 是 一 件 多 么 痒 福 的 事情 ， 退 求 一 个 女生 可 以 多 次 反复 地 实 
验 ， 直 到 找到 好 的 方法 和 途径 为 止 ， 这 估计 是 大 多 数 男生 都 布 望 获得 
的 特异 功能 。 想 想 看 ， 看 到 一 个 心仪 的 女生 ， 我 们 大 反复 壬 试 ， 总 会 
有 一 个 方法 打动 她 的 ， 多 美好 的 一 件 事 。 现 在 我 们 还 得 回 到 现实 生 
活 ， 我 们 来 分 析 一 下 类 似 事情 的 经 过 : 


e 复制 一 个 当前 状态 ,保留 下 米 ， 这 个 状态 束 是 等 会 儿 搭 训 女 孩子 
失败 后 要 恢复 的 状态 ， 你 不 恢复 原始 状态 ， 这 不 束 露 饼 儿 了 吗 ? 


e 每 次 试探 性 笑 试 失败 后 ， 都 必须 恢复 到 这 个 原始 状态 。 


e N 次 试探 总 有 一 次 成 功 吧 ， 成 功 以 后 即 可 走 成 功 路 线 。 


想 想 看 ， 我 们 这 里 的 场景 中 最 重要 的 是 哪 一 块 ? 对 的 ， 征 原始 状 
态 的 保留 和 恢复 这 块 ， 如 何 保留 一 个 原始 ， 如 何 恢 复 一 个 原始 状态 才 
征 最 重要 的 ， 那 想 想 看 ， 我 们 应 该 怎么 实现 呢 ? 很 简单 呀 ， 我 们 可 以 
定义 一 个 中 间 变 量 ， 保 留 这 个 原始 状态 。 我 们 先 看 看 类 图 ， 如 图 24-1 所 


修 ° 


+void changeState() 
+String getState() 


Client 


+Vold setState(String state) 


图 24-1 男孩 状态 类 图 


太 人 简单 的 类 图 了 ， 我 们 来 解释 一 下 图 中 的 状态 state 征 什么 意思 ， 在 
某 一 时 间 点 的 所 有 位 置信 息 、 心 理 信 息 、 环 境 信息 都 属于 状态 ， 我 们 
这 里 用 了 一 个 标识 性 的 名 词 state 代 表 所 有 状态 ， 比 如 在 退 女 孩子 前 心情 
是 期 待 、 心 理 是 焦躁 不 安 等 。 次 去 认识 女孩 子 都 是 会 发 生 状 态 变 
化 的 ， 我 们 使 用 changeState 方 法 来 代替 ， 由 于 程序 比较 簿 单 ， 就 没有 编 
写 接口 ， 我 们 来 看 实现 ， 如 代码 清单 24-1 所 示 。 


代码 清单 24-1 男孩 状态 类 


public class Boy { 
// 男 孩 的 状态 
private String state = "”"; 
// 认 识 女 孩子 后 状态 肯定 改变 ， 比 如 心情 、 手 中 的 花 等 
public void changeState( ){ 
this.state = "心情 可 能 很 不 好 "，; 


} 
public String getState() { 


return State ， 


public void setState(String state) { 
this.state = state; 
} 


程序 是 很 简单 ， 主 要 的 业务 逻辑 是 在 场景 类 中 ， 我 们 来 看 场景 ; 
征 如 何 进行 状态 的 保留 、 恢 复 的 ， 如 代码 清单 24-2 所 示 。 


代码 清单 24-2 场景 


public class Client { 
public static void main(String[] args) { 
// 声 明 出 主角 
Boy boy = new Boy( ) ; 
// 初 始 化 当前 状态 
boy ,setstate(u 心 情 很 棒 ! " ) ; 


System. out .println("===== 男 孩 现在 的 状态 ======"); 
System.out.printJln(boy,.getState() ) ; 
// 需 要 记录 下 当前 状态 呀 


Boy backup = new Boy() ; 
backup.setState(boy.getstate()); 

// 男 孩 去 追 女 孩 ， 状 态 改变 

boy .changeState() ; 
System.out.println("NXn===== 男 孩 追 女孩 子 后 的 状态 


System.out.printJln(boy,.getState() ) ; 
// 追 女孩 失败 ， 恢 复原 状 

boy ,SetState(backup .getState() ) ; 
System.out .println("NXn===== 男 孩 恢 复 
System.out.println(boy,.getState() ) ; 
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程序 运行 结果 如 下 所 示 : 


心情 很 棒 ! 


心情 可 能 很 不 好 


程序 运行 正确 ， 输 出 结果 也 是 我 们 期 望 的 ， 但 是 结果 正确 并 不 表 
示 程 序 是 最 优 的 ， 我 们 来 看 看 场景 类 Client， 它 代表 的 是 高 层 模 块 ， 或 
者 说 是 非 “ 近 杀 ” 模 块 的 调用 者 ， 注 意 看 backup 变 量 的 使 用 ， 它 对 于 高 层 
模块 完全 是 多 余 的 ， 为 什么 一 个 状态 的 保存 和 恢复 要 让 高 层 模块 来 负 
责 呢 ? 这 应 该 是 Boy 类 的 职责 ， 而 不 应 该 让 高 层 模块 来 完成 ， 也 台 是 破 
坏 了 Boy 类 的 封 逆 ， 或 者 说 Boy 类 没有 封 闻 好 ， 它 应 该 是 把 backup 的 定 
义 容 纳 进来 ， 而 不 应 该 让 高 层 模块 来 定义 。 


问题 我 们 已 经 知道 了 了， 就 是 Boy 类 封 半 不 够 ， 那 我 们 应 该 如 何 修改 
呢 ? 如 果 在 Boy 类 中 再 增加 一 个 方法 或 者 其 他 的 内 部 类 来 保存 这 个 状 
态 ， 则 对 单一 职责 原则 是 一 种 破坏 ， 想 想 看 单一 职责 原则 是 怎么 说 
的 ? 一 个 类 的 职责 应 该 是 单一 的 ，Boy 类 本 身 的 职责 是 追求 女孩 子 ， 而 
保留 和 恢复 原始 状态 则 应 该 由 另外 一 个 类 来 承担 ， 那 我 们 把 这 个 类 取 
名 就 叫做 备忘录 ， 这 和 大 家 经 常 在 桌面 上 贴 的 那个 便签 是 一 个 概念 ， 
分 析 到 这 里 我 们 的 思路 已 经 非常 清 芭 了 ， 我 们 来 修改 一 下 类 图 ， 如 图 
24-2 所 示 。 


+Vvold change State() 

+String getState() 

+void setState(String state) 
+Memento create Memento() 

+Vold restoreMemento(Memento memento) 


Client 


图 24-2 完 去 后 的 男孩 状态 类 图 


改动 很 小 ， 增 加 了 一 个 新 的 类 Memento， 人 负责 状态 的 保存 和 备份 ; 
同时 ， 在 Boy 类 中 增加 了 创建 一 份 备 忘 录 createMemento 和 恢复 一 个 备 起 
录 resotreMemento， 我 们 先 来 看 Boy 类 的 变化 ， 如 代码 清单 24-3 所 示 。 


代码 清单 24-3 改进 后 的 男孩 状态 类 


public class Boy { 
// 男 孩 的 状态 
private String state = ""; 
// 认 识 女 孩子 后 状态 肯定 改变 ， 比 如 心情 、 手 中 的 花 等 
public void changeState( ){ 
this.state = "心情 可 能 很 不 好 "，; 


} 
public String getState() { 
return state,; 


} 
public void setState(String state) { 
this.state = state; 


} 
// 保 留 一 个 备份 
public Memento createMemento( ){ 


return new Memento(this.state); 


} 

// 恢 复 一 个 备份 
public void restoreMemento(Memento _memento)t{ 
this.setSstate(_ memento.getState()); 

} 


注意 看 ， 确 实 只 增加 了 两 个 方法 创建 备份 和 恢复 备份 ， 至 于 在 什 
么 时 候 创建 备份 和 恢复 备份 则 是 由 高 层 模块 决定 的 。 我 们 再 来 看 备 起 
隶 模块 ， 如 代码 清单 24-4 所 示 。 


代码 清 单 24- 4 备 万 3 


public class Memento { 
// 男 孩 的 状态 
private String state = 
// 通 过 构造 函数 传递 状态 信息 
public Memento(String _state){ 
this.state = _state; 


TI 
了 


} 
public String getState() { 
return state; 


} 

public void setState(String state) { 
this.state = state; 

} 


这 就 是 一 个 简单 的 JavaBean， 保 留 男 骇 当 时 的 状态 信息 。 我 们 再 来 
看 场景 类 ， 稍 做 修改 ， 如 代码 清单 24-5 所 示 。 


代码 清单 24-5 改进 后 的 场景 


public class Client { 
public static void main(String[] args) { 
// 声 明 出 主角 
Boy boy = new Boy( ) ; 
// 初 始 化 当前 状态 


boy .setstate( "心情 很 棒 ! ") ; 
System,out,.println("===== 男 孩 现 在 的 状态 ======") 
System,out ,printlLn(boy.getState() )， 

// 需 要 记录 下 当前 状态 呀 

Memento mem = boy.createMemento(); 

// 男 孩 去 追 女孩 ， 状 态 改变 

boy ,changeState( ) ; 
System.out.println("NXn===== 男 孩 追 女孩 子 后 的 状态 


System,out ,println(boy.getState())， 

// 追 女孩 失败 ， 恢 复原 状 

boy ,restoreMemento(mem) 
System,out,.println("NXn===== 男 孩 恢复 后 的 状态 ======") 
System.out.printlin(boy.getstate( )); 


一 


运行 结果 保持 相同 ， 虽 然 程 序 中 不 再 重复 定义 Boy 类 的 对 象 了 ， 但 
征 我 们 还 是 要 关心 备 二 未 ， 这 对 迪 米 特 法 则 下 一 个 讲 汪 ， 它 告诉 我 们 
只 和 朋友 类 通信 ， 那 这 个 备 起 杂 对 象 古 我 们 必须 要 通信 的 朋友 类 吗 ? 
对 高 层 模块 来 说 ， 它 最 硕 望 要 做 的 就 是 创建 一 个 备份 扣 ， 然 后 在 需 
的 时 候 再 恢复 到 这 个 备份 点 束 成 了 ， 写 不 用 关心 到 搬 有 没有 备 环 孙 这 
个 类 。 那 根据 这 一 指导 思想 ， 我 们 就 需要 把 备 起 录 类 再 包装 一 下 ， 起 
么 包装 呢 ? 建 立 一 个 管理 类 ， 就 古 管理 这 个 备 坪 录 ， 如 图 24-3 所 示 。 


-Memento memento 


i ee “ih +Memento get Memento() 
ring getState() +void setMemento(Memento memento) 
+void setState(String state) F r 
! : 


+Memento create Memento() 
+void restore Memento(Memento memento) 


图 24-3 完整 的 男孩 妃 女 生 类 图 


又 增加 了 一 个 JavaBean，Boy 类 和 Memento 没 有 任何 改变 ， 不 再 玖 
述 。 我 们 来 看 增加 的 备 走 录 管 理 类 ， 如 代码 清单 24-6 所 示 。 


代码 清单 24-6 备 雯 录 管 理 者 


public class Caretaker { 
// 备 记录 对 象 
private Memento memento; 
public Memento getMemento() { 
return memento; 


public void setMemento(Memento memento) { 
this.memento = memento， 
} 


个 太 简 单 了 ， 非 常 纯粹 的 一 个 JavaBean， 重 管 它 多 人 简单， 只 要 有 
用 束 成 ， 我 们 来 看 场景 类 如 何 调用 ， 如 代码 清单 24-7 所 示 。 


代码 清单 24-7 进一步 改进 后 的 场景 类 


public class Client { 
public static void main(String[] args) { 

// 声 明 出 主角 
Boy boy = new Boy( ) ; 
// 声 明 出 三 忘 录 的 管理 考 
caretaker caretaker = new Caretaker(); 
// 初 始 化 当前 状态 
boy .setstate( "心情 很 棱 !")， 


System.out. print1ln("===== 男 孩 现在 的 状态 ======" ) ; 
System.out.printJln(boy,.getState() ) ; 
// 需 要 记录 下 当前 状态 呀 


caretaker .setMemento(boy ,createMemento( ) ) ; 
// 男 孩 去 追 女 孩 ， 状 态 改变 

boy .changeState() ; 
System,out,.println("NXn===== 男 孩 追 女孩 子 后 的 状态 


System.out.printJln(boy,.getState() ) ; 
// 追 女孩 失败 ， 恢 复原 状 


boy ,restoreMemento(caretaker .getMemento( ) ) ; 


System,out,.println("NXn===== 男 孩 恢复 后 的 状态 ======") 
System,out ,println(boy.getState())， 


注意 看 黑体 部 分 ， 束 修改 了 这 么 多 ， 看 看 程序 的 逻辑 是 不 是 清晰 
了 很 多 ， 需 要 备份 的 时 候 就 创建 一 个 备份 ， 然 后 丢 给 备 乐 孙 管 理 者 进 
行 管理 ， 要 取 的 时 候 再 从 管理 者 手中 拿 到 这 个 备份 。 这 个 备份 者 就 类 
似 于 一 个 备份 的 仓库 管理 员 ， 创 建 一 个 丢 进 去 ， 需 要 的 时 候 再 拿 出 
来 。 这 了 吏 是 备 还 永 模 式 。 


24.2 备 护 杂 模 式 的 定义 


备 态 录 模 式 (Memento Pattern) 提供 了 一 种 弥补 真实 世界 缺陷 的 
方法 ， 让 “后 悔 药 ”在 程序 的 世界 中 真实 可 行 ， 其 定义 如 下 : 


Without violating encapsulation,capture and externalize an object's 
internal state so that the object can be restored to this state later 〈 在 不 破坏 
封 竣 性 的 前 担 下 ， 捕 获 一 个 对 象 的 内 部 状态 ， 并 在 该 对 象 之 外 保存 这 
个 状态 。 这 样 以 后 就 可 将 该 对 象 恢复 到 原先 保存 的 状态 。) 


通俗 地 说 ， 备 起 录 模 式 束 是 一 个 对 象 的 备份 模式 ， 提 供 了 一 种 程 
序数 据 的 备份 方法 ， 其 通用 类 图 如 图 24-4 所 示 。 


Memento 

EE 一 3 

+SetMemento(m: Memento) +GetState() 
+CreateMemento() +SetState() 


图 24-4 备 起 杂 模 式 的 通用 类 图 


+menento 


我 们 来 看 看 类 图 中 的 三 个 角色 。 


e Originator 发 起 人 角色 


记录 当前 时 刻 的 内 部 状态 ， 负 责 定 义 哪些 属于 备份 范围 的 状态 ， 
负责 创建 和 恢复 备 起 录 数 据 。 


e Memento 备 态 好 角色 


负责 存储 Originator 发 起 人 对 象 的 内 部 状态 ， 在 需要 的 时 候 提供 发 
起 人 需要 的 内 部 状态 。 


e Caretaker 备 态 杂 管理 员 角 色 
对 备 乓 好 进行 管理 、 保 存 和 提供 备 态 5 


备 拟 杂 模 式 的 通用 代码 也 非常 人 简单， 我们 先 看 发 起 人 角色 ， 如 代 
码 清单 24-8 所 示 。 


代码 清单 24-8 发 起 人 角色 


public class Originator { 
// 内 部 状态 


private String state = ""; 


public String getState() { 
return state,; 


public void setState(String state) { 
this.state = state,; 


} 
// 创 建 一 个 备 起 孙 
public Memento createMemento( ){ 
return new Memento(this.state); 


} 

// 恢 复 一 个 备忘录 

public void restoreMemento(Memento _memento)t{ 
this.setSstate(_ memento.getState()); 


一 


我 相信 你 心里 此 刻 有 很 多 疑问 ， 比 如 状态 是 多 个 怎么 办 ? 需要 有 
多 份 备份 怎么 办 ? 如 果 你 很 着 急 的 话 ， 请 看 24.4 节 ， 但 我 建议 你 还 是 跟 
随 我 一 步 一 步 地 走 ， 我 们 再 来 看 备 起 杂 角 色 ， 如 代码 清单 24-9 所 示 。 


代码 清单 24-9 备忘录 角色 


public class Memento { 
// 发 起 人 的 内 部 状态 
private String state = ""; 
// 构 造 画 数 传递 参数 
public Memento(String _state){ 
this.state = _state,; 


} 
public String getState() { 
return state; 


public void setState(String state) { 
this.state = state,; 
} 


这 是 一 个 人 简单 的 JavaBean, 备 护 杂 管理 着 也 是 一 个 简单 的 


JavaBean， 如 代码 清单 24-10 所 示 。 


代码 清单 24-10 备忘录 管理 员 和 角色 


public class Caretaker { 
// 备 记录 对 象 
private Memento memento; 
public Memento getMemento() { 
return memento; 


public void setMemento(Memento memento) { 
this.memento = memento， 
} 


这 3 个 主要 角色 都 很 测 单 ， 我 们 来 看 场景 类 如 何 调用 ， 如 代码 请 单 


24-11 所 示 。 


代码 清单 24-11 场景 类 


public class Client { 
public static void main(String[] args) { 

// 定 义 出 发 起 人 
Originator originator = new Originator(); 
// 定 义 出 备忘录 管理 员 
Caretaker caretaker = new Caretaker(); 
// 创 建 一 个 备 起 5 
Gar ota Set Meno oo createMemento( ) ) ; 
// 恢 复 一 个 备 起 录 
originator.restoreMemento(caretaker .getMemento( ) ) ; 


一 
一 


还 永 模 式 束 生 这 么 简单 ， 真 正 使 用 备 环 孙 模 式 的 时 候 可 比 这 复 


24.3 备 环 永恒 式 的 应 用 


由 于 备忘录 模式 有 太 多 的 变形 和 处 理 方式 ， 每 种 方式 都 有 它 自 己 
的 优点 和 缺点 ， 标 准 的 备 起 录 模 式 很 难 在 项 目 中 直到 ， 基 本 上 部 有 一 
些 变换 处 理 方式 。 因 此 ， 我 们 在 使 用 备 起 录 模 式 时 主要 了 解 如 何 应 用 
以 及 需要 注意 哪些 事项 就 成 了 。 


24.3.1 备 扑 杂 模 式 的 使 用 场景 


e 需要 保存 和 恢复 数据 的 相关 状态 场景 。 


e 提供 一 个 可 回 滚 (rollback) 的 操作 ;比如 Word 中 的 CTRL+Z 组 
合 键 ， 正 浏览 右 中 的 后 退 按钮 ， 文 件 管理 右上 的 backspace 键 等 。 


e 需要 监控 的 副本 场景 中 。 例 如 要 监控 一 个 对 象 的 属性 ， 但 是 监 
控 又 不 应 该 作为 系统 的 主 业务 来 调用 ， 它 只 是 边缘 应用， 即使 出 现 监 
探 不 准 、 错 旋 报 警 也 影响 不 大 ， 因 此 一 般 的 做 法 是 备份 一 个 主线 程 中 
的 对 象 ， 然 后 由 分 析 程 序 来 分 析 。 


e 数据 库 连 接 的 事务 管理 吏 是 用 的 备 环 孙 模 式 ， 想 想 看 ， 如 果 你 
要 实现 一 个 JDBC 驱 动 ， 你 怎么 来 实现 事务 ”还 不 是 用 备 环 孙 模式 嘛 |， 


24.3.2 备 还 永 模 式 的 注意 事项 


e 备 乓 杂 的 生命 期 


备 护 好 创建 出 来 号 要 在 “最 近 ” 的 代码 中 使 用 ， 要 主动 管理 它 的 生 
命 周 期 ， 建 立 束 要 使 用 ， 不 使 用 束 要 立刻 删除 其 引用 ， 等 得 垃圾 回收 
妖 对 它 的 回收 处 理 。 


e 备 态 杂 的 性 能 


不 要 在 频繁 建立 备份 的 场景 中 使 用 备 喜 录 模式 (比如 一 个 for 循 环 
中 ) ， 原 因 有 二 : 一 是 控制 不 了 备 态 录 建立 的 对 象 数 量 ， 二 是 大 对 象 
的 建立 是 要 消耗 资源 的 ， 系 统 的 性 能 需要 考虑 。 因 此 ， 如 有 果 出 现 这 样 
的 代码 ， 设 计 师 就 应 该 好 好 想 想 怎 么 修改 架构 了 。 


24.4 备 乓 杂 模 式 的 扩展 


24.4.1 clone 方 式 的 备 态 有 杂 


大 家 还 记得 在 第 13 间 中 讲 的 原型 模式 吗 ? 我 们 可 以 通过 复制 的 方 
式 产 生 一 个 对 象 的 内 部 状态 ， 这 是 一 个 很 好 的 办 法 ， 发 起 人 角色 只 
实现 Cloneable 就 成 ， 比 较 人 简单 ， 我 们 来 看 类 图 ， 如 图 24-5 所 示 。 


<<interface>> 
Cloneable 


-Originator origmator 


+Originator getOriginator() 
+void setOrigimator(Origimator originator) 


图 24-5 Clone 方 式 的 备 扎 录 


‘| +Originator createMemento() 
+void restore Memento(Originator _originator) 
+Originator clone() 


从 类 图 上 看 ， 发 起 人 角色 融合 了 发 起 人 角色 和 备 起 好 角色 ， 具 有 
双重 功效 ， 如 代码 清单 24-12 所 示 。 


代码 清单 24-12 融合 备 起 杂 的 发 起 人 角色 


public class Originator implements Cloneablef{ 
// 内 部 状态 


private String state = ""，; 


public String getState() { 


return State ， 


public void setState(String state) { 
this.state = state,; 


} 

// 创 建 一 个 备 起 录 

public Originator createMemento(){ 
return this.clone(); 


} 

// 恢 复 一 个 备忘录 

public void restoreMemento(Originator _originator)t{ 
this.setSstate(_originator .getState() ) ; 


} 

/7 克隆 当 前 对 象 

@Override 

protected Originator clone()t{ 


try { 
return (Originator)super.clone(); 
} catch (CloneNotSupportedException e) { 
e.printStackTrace(); 


return null; 


增加 了 clone 方 法 ， 产 生 了 一 个 备份 对 象 ， 需 要 使 用 的 时 候 再 还 
原 ， 我 们 再 来 看 管理 员 角 色 ， 如 代码 清单 24-13 所 示 。 


代码 清单 24-13 备忘录 管理 员 角 色 


public class Caretaker { 
// 发 起 人 对 象 
private Originator originator; 
public Originator getOriginator() { 
return originator; 


public void setOriginator(Originator originator) { 
this.originator = originator; 
} 


没什么 太 大 变化 ， 只 走 备 环 孙 角 色 转 换 成 了 发 起 人 角色 ， 还 是 一 

个 简单 的 JavaBean。 我 们 来 想 想 这 种 模式 是 不 是 还 可 以 催化 ? 要 管理 员 
角色 干什么 ? 束 是 为 了 管理 备 环 孙 角 色 ， 现 在 连 备 环 孙 角 色 都 被 合并 
， 还 留 着 它 干 吗 ? 我 们 想 办 法 把 它 也 精简 掉 ， 如 代码 清单 24-14 所 


修 ° 


代码 清单 24-14 发 起 人 目 主 备份 和 恢复 


public class Originator implements Cloneablef{ 
private Originator backup; 
// 内 部 状态 
private String state = ""，; 
public String getState() { 
return state; 


public void setState(String state) { 
this.state = state,; 


} 

// 创 建 一 个 备 态 3 

public void createMemento( ){ 
this.backup = this.clone(); 


} 

// 恢 复 一 个 备忘录 

public void restoreMemento( ){ 
// 在 进行 恢复 前 应 该 进行 断言 ， 防 止 空 指针 
this.setState(this.backup.getState()); 


} 

// 克 隆 当 前 对 象 

Q@Override 

protected Originator clone(){ 
try { 


return (Originator)super.clone(); 
} catch (CloneNotSupportedException e) { 
e.printStackTrace() ; 


return null; 


可 能 你 要 发 问 了 ， 这 和 备 起 好 模式 的 定义 不 相符 ， 它 定义 古 “ 在 该 
对 象 之 外 保存 这 个 状态 ”， 而 你 却 把 这 个 状态 保存 在 了 发 起 人 内 部 。 是 
的 ， 设 计 模式 定义 的 诞生 比 Java 的 出 世上 略 早 ， 它 没有 想到 Java 程 序 古 这 
么 有 活力 ， 有 远见 ， 而 且 在 面向 对 象 的 设计 中 ， 即 使 把 一 个 类 封装 在 
另 一 个 类 中 也 是 可 以 做 到 的 ， 何 况 一 个 小 小 的 对 象 复制 ， 这 是 它 的 设 
计 模 式 完 全 没有 预见 到 的 ， 我 们 把 它 弥 补 回来 。 


再 来 看 看 Client 是 如 何 调用 的 ， 如 代码 清单 24-15 所 示 。 


代码 清单 24-15 场景 类 


public class Client { 
public static void main(String[] args) { 
// 定 义 发 起 人 
Originator originator = new Originator(); 
// 建 立 初始 状态 
originator .setState(" 初 始 状态 ,.."); 
System.out.println(" 初 始 状 态 


是 : "+originator.getState()); 
// 建 立 备份 
originator.createMemento( ); 
// 修 改 状态 
originator .setState(" 修 改 后 的 状态 ..."); 
System.out.println(" 修 改 后 状态 
是 : "+originator.getState()); 
// 恢 复原 有 状态 
originator ,restoreMemento( ) ; 
System.out.println(" 恢 复 后 状态 
是 : "+originator .getState()); 
} 


运行 结果 如 下 所 示 : 


初始 状态 是 : 初始 状态 .. 


修改 后 状态 是 : 修改 后 的 状态 .… 


恢复 后 状态 是 : 初始 状态 .… 


运行 结果 是 我 们 所 希望 的 ， 程 序 精简 了 很 多 ， 而 且 高 层 模 块 的 依 
赖 也 减少 了 ， 这 正 是 我 们 期 记 的 效果 。 现 在 我 们 来 考虑 一 下 原型 模式 
深 找 贝 和 浅 拷贝 的 问题 ， 在 复杂 的 场景 下 它 会 让 你 的 程序 逻辑 异常 混 
乱 ， 出 现 错误 也 很 难 跟踪 。 因 此 Clone 方 式 的 备忘录 模式 适用 于 较 简 单 
的 场景 。 


注意 ”使 用 Clone 方 式 的 备 起 录 模 式 ， 可 以 使 用 在 比较 简单 的 场景 
或 者 比较 单一 的 场景 中 ， 尽 量 不 要 与 其 他 的 对 象 产 生产 重 的 耦合 关 
过 


24.4.2 多 状态 的 备 访 录 模 式 


读者 应 该 看 到 我 们 以 上 讲解 都 是 单 状 态 的 情况 ， 在 实际 的 开发 中 
一 个 对 象 不 可 能 只 有 一 个 状态 ， 一 个 JavaBean 有 多 个 属性 非常 常见 ， 这 
都 是 它 的 状态 ， 如 果 照 搬 我 们 以 上 讲解 的 备 筷 孙 模 式 ， 是 不 是 就 要 写 
一 堆 的 状态 备份 、 还 原 语句 ? 这 不 是 一 个 好 办 法 ， 这 种 类 似 的 非 智力 
劳动 越 多 ， 犯 错误 的 几率 越 大 ， 那 我 们 有 什么 办 法 来 处 理 多 个 状态 的 


备份 问题 呢 ? 


下 面 我 们 来 讲解 一 个 对 象 全 状态 备份 方案 ， 它 有 多 种 处 理 方式 ， 
比如 使 用 Clone 的 方式 束 可 以 解决 ， 使 用 数据 技术 也 可 以 解决 (DTO 回 


写 到 临时 表 中 ) 等 ， 我 们 要 讲 的 方案 就 对 备 起 录 模 式 继续 扩展 一 下 ， 
实现 一 个 JavaBean 对 象 的 所 有 状态 的 备份 和 还 原 ， 如 图 24-6 所 示 。 


Memento 


_ | -HashMap<String,Object> stateMap 
+getter/setter() 


+getter/setter() 


-Strmg statel 
-String state2 
-String state3 


+getter/setter() 


+static Hash Map<String,Object> backupProp(Object bean) 
+static void restoreProp(Object bean, Hash Map<String, Object> propMap) 


图 24-6 多 状态 的 备 环 孙 模 式 


还 是 比较 人 简单 的 类 图 ， 增 加 了 一 个 BeanUtils 类 ， 其 中 backupProp 是 
把 发 起 人 的 所 有 属性 值 转换 到 HashMap 中 ， 方 便 备忘录 角色 存储 ; 
restoreProp 方 法 则 是 把 HashMap 中 的 值 返 回 到 发 起 人 角色 中 。 可 能 各 位 
要 说 了 ， 为 什么 要 使 用 HashMap， 直 接 使 用 Originator 对 象 的 拷贝 不 是 
一 个 很 好 的 方法 吗 ? 可 以 这 样 做 ， 你 束 破 坏 了 发 起 人 的 通用 性 ， 你 在 
做 恢复 动作 的 时 候 需 要 对 该 对 象 进行 多 次 赋值 操作 ， 也 容易 产生 错 
误 。 我 们 先 来 看 发 起 人 角色 ， 如 代码 清单 24-16 所 示 。 


代码 清单 24-16 发 起 人 角色 


public class Originator { 
// 内 部 状态 
private String statel 
private String state2 
private String state3 
public String getState 
return Statel; 


Cj 
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} 
public void setState1(String state1) { 
this,.state1 = statel,; 


} 
public String getState2() { 
return state2; 


} 
public void setState2(String state2) { 
this.state2 = state2; 


} 
public String getState3() { 
return state3; 


} 
public void setState3(String state3) { 
this.state3 = state3; 


} 
// 创 建 一 个 备 起 了 隶 
public Memento createMemento( ){ 
return new Memento(BeanUtils.backupProp(this)); 


} 
// 恢 复 一 个 备忘录 
public void restoreMemento(Memento _memento)t{ 
BeanUtils.restoreprop(this, 
_memento.getStateMap()); 


} 
// 增 加 一 个 toString 方 法 
@Override 
public String toString(){ 
return "State1=" 
+statei+"\nstat2="+state2+"\nstate3="+state3; 


} 


徐 写 toString 方 法 是 为 了 方便 打印 ， 可 以 让 展示 的 结 末 更 清晰 。 我 
们 再 来 看 BeanUtils 工 具 类 ， 如 代码 清单 24-17 所 示 。 


代码 清单 24-17 BeanUtils 工 具 类 


public class BeanUtils { 

// 把 bean 的 所 有 属性 及 数值 放 入 到 Hashmap 中 

public static HashMap<String,Object> backupProp(Object 
bean){ 


HashMap<String,Object> result = new 
HashMap<String,Object>(); 


try { 


// 获 得 Bean 描 述 
BeanInfo 
beanInfo=Introspector ,getBeanInfol(bean,getClass() )， 
// 获 得 属性 描述 
PropertyDescriptor[] 
descriptors=beanInfo.getPropertyDescriptors(); 
// 遍 历 所 有 属性 
for(PropertyDescriptor des:descriptors)t{ 
// 属 性 名 称 
String fieldName = des.getName(); 
// 读 取 属 性 的 方法 
Method getter = 


// 读 取 属 性 值 
Object 
fieldvValue=getter.invoke(bean,new Object[]{}); 
if(!fieldName.equalsIgnoreCase("class"))t 
result.put(fieldName, fieldValue); 
} 


} catch (Exception e) { 
// 异 常 处 理 
} 


return result,; 


des ,getReadMethod ( ) ; 


} 
// 把 HashMap 的 值 返回 到 bean 中 
public static void restoreProp(Object 
bean,HashMap<String,Object> propMap)t{ 
try { 
// 获 得 Bean 描 j 
BeanInfo beanInfo = 
Introspector .getBeanInfol(bean ,getClass() ) ; 
// 获 得 属性 描述 
PropertyDescriptor[] descriptors = 
beanInfo.getPropertyDescriptors(); 
// 遍 历 所 有 属性 
for(PropertyDescriptor des:descriptors)t{ 
// 属 性 名 称 
String fieldName = des.getName(); 
// 如 果 有 这 个 属性 


~ 
二 


if(propMap.containskey(fieldName)){ 
// 写 属性 的 方法 
Method setter = des.getwriteMethod(); 
setter.invoke(bean, new Object[] 
{propMap.get(fieldName)}); 
} 


} 
} catch (Exception e) { 
异常 处 理 
System.out.println("shit"); 
e.printStackTrace() ; 


该 类 大 家 在 项 目 中 会 经 常用 到 ， 可 以 作为 参考 使 用 。 类 似 的 功能 
有 很 多 工具 已 经 提供 ， 比 如 Spring、Apache 工 具 集 commons 等 ， 大 家 也 
可 以 直接 使 用 。 我 们 再 来 看 备 走 录 和 角色， 如 代码 清单 24-18 所 示 。 


代码 清单 24-18 备忘录 角色 


public class Memento { 
// 接 受 HashMap 作 为 状态 
private HashMap<String,Object> stateMap; 
// 接 受 一 个 对 象 ， 建 立 一 个 备份 
public Memento(HashMap<String,Object> map)t{ 
this.stateMap = map; 


} 
public HashMap<String,Object> getStateMap() { 
return stateMap; 


} 

public void setStateMap(HashMap<String,Object> stateMap) { 
this.stateMap = stateMap; 

} 


我 们 再 编写 一 个 场景 类 ， 看 看 我 们 的 成 果 是 否 正 确 ， 如 代码 清单 
24-19 所 示 。 


代码 清单 24-19 场景 


public class Client { 
public static void main(String[] args) { 


一 


// 定 义 出 发 起 人 

Originator ori = new Originator(); 

// 定 义 出 备忘录 管理 员 

Caretaker caretaker = new Caretaker(); 
// 初 始 化 
ori.setState1(" 中 国 " ) ; 

ori, setState2(" 强 尤 ") ; 

ori.setstate3(" 繁 荣 ")， 

System.out .print1n("=== 初 始 化 状态 ===\n"+ori); 
// 创 建 一 个 备 护 录 
caretaker.setMemento(ori.createMemento( )); 
// 修 改 状态 值 
ori. setSstate1(" 软 件 "); 

ori, setState2(" 架 构 "); 

ori,setState3(" 优 秀 " ) ， 

System,.out .println("\n=== 修 改 后 状态 ===\n"+ori)，; 
// 恢 复 一 个 备忘录 

he a te eh bh 


区 


运行 结果 如 下 所 示 : 


=== 初 始 化 状 ; 


state1= 中 
stat2= 强 盛 


state3= 繁 荣 


| 


N= 三 三 


=== 修 改 后 状态 === 


state1= 软 件 
stat2= 架 构 


state3= 优 秀 


-== 恢 复 后 状态 === 


state1= 中 国 
stat2= 强 盛 


state3= 繁 琳 


通过 这 种 方式 的 改造 ， 不 管 有 多 少 状态 都 没有 问题 ， 直 搂 把 原 有 
的 对 象 所 有 属性 都 备份 了 一 过 ， 想 恢复 当时 的 点 数据 ” 那 太 容易 了 ! 


注意 ”如果 要 设计 一 个 在 运行 期 决定 备份 状态 的 框架 ， 则 建议 采 
用 AOP 框 回来 实现 ， 避 人 免 采 用 动态 代理 无 请 地 增加 程序 逻辑 复杂 性 。 


24.4.3 多 备份 的 备 起 录 


不 知道 你 有 没有 做 过 系统 级 别 的 维护 ? 比如 Backup Administrator 
(备份 管理 员 ) ， 每 天 负责 查看 系统 的 备份 情况 ， 所 有 的 备份 都 是 由 
目 动 化 脚本 产生 的 。 有 一 天 ， 突 然 有 一 个 重要 的 系统 说 我 数据 库 有 所 
问题 ， 请 把 上 一 个 月 末 的 数据 拉 出 来 恢复 ， 那 怎么 办 ? 对 备份 管理 员 
来 说 ， 这 很 好 办 ， 直 接 根 据 时 间 礁 找到 这 个 备份 ， 还 原 回 去 就 成 了 ， 
但 是 对 于 我 们 刚刚 学 习 的 备 起 好 模式 却 行 不 通 ， 为 什么 呢 ? 它 对 于 一 
个 确定 的 发 起 人 ， 永 远 只 有 一 份 备份 ， 在 这 种 情况 下 ， 单 一 的 备份 区 
不 能 满足 要 求 了 ， 我 们 需要 设计 一 套 多 备份 的 架构 。 


我 们 先 来 说 一 个 名 词 ， 检 查 点 (Check Point) ， 也 就 是 你 在 备份 
的 时 候 做 的 戳记 ， 系 统 级 的 备份 一 般 是 时 间 戳 ， 那 我 们 程序 的 检查 点 
该 皇 么 设计 呢 ? 一 般 是 一 个 有 意义 的 字符 串 。 


我 们 只 要 把 通用 代码 中 的 Caretaker 管 理 员 稍 做 修改 就 可 以 了 ， 如 
代码 清单 24-20 所 示 。 


代码 清单 24-20 备忘录 管理 员 


public class Caretaker { 
// 容 纳 备忘录 的 容器 
private HashMap<String,Memento> memMap = new 
HashMap<String,Memento>(); 
public Memento getMemento(String idx) { 
return memMap.get(idx); 


public void setMemento(String idx,Memento memento) { 
this.memMap.put(idx, memento); 
} 


把 容纳 备忘录 的 容器 修改 为 Map 类 型 就 可 以 了 ， 场 景 类 也 稍 做 改 
动 ， 如 代码 清单 24-21 所 示 。 


代码 清单 24-21 场景 类 


public class Client { 
public static void main(String[] args) { 
// 定 义 出 发 起 人 
Originator originator = new Originator(); 
// 定 义 出 备忘录 管理 员 
Caretaker caretaker = new Caretaker(); 


// 创 建 两 个 备 环 永 


caretaker .setMemento("001" ,originator ,createMemento( ) ) ; 


caretaker .setMemento("002",originator.createMemento( )); 
// 恢 复 一 个 指定 标记 的 备忘录 


originator.restoreMemento(caretaker .getMemento("001")); 


) 


注 划 ”内 存 洲 出 问题 ， 该 备份 一 旦 产生 就 装 入 内 存 ， 没 有 任何 销 
毁 的 意向 ， 这 是 非常 危险 的 。 因 此 ， 在 系统 设计 时 ， 要 严格 限定 备 环 
孙 的 创建 ， 建 议 增加 Map 的 上 限 ， 否 则 系统 很 容易 产生 内 存 淤 出 情况 。 


24.4.4 封装 得 更 好 一 点 


在 系统 管理 上 ， 一 个 备份 的 数据 是 完全 、 绝 对 不 能 修改 的 ， 它 祭 
证 数据 的 洁净 ， 避 免 数据 污染 而 使 备份 失去 意义 。 在 我 们 的 设计 领域 
中 ， 也 存在 着 同样 的 问题 ， 备 份 是 不 能 被 自 改 的 ， 也 就 是 说 需要 缩小 
备份 出 的 备 起 录 的 阅读 权限 ， 保 证 只 能 是 发 起 人 可 读 束 成 了 ， 那 怎么 
才能 做 到 这 一 点 呢 ? 使 用 内 置 类 ， 如 图 24-7 所 示 。 


Caretaker 


<<interface>> 
-String state 


IMemento -IMemento memento 


ee 
+getter/setter() 
+IMemento create Memento() 


+void restore Memento(IMemento memento) 


| 
IE +getter/setter() 


内 部 类 


-String getState() 
-void setState(String state) 


图 24-7 使 用 内 置 类 的 备 起 如 模式 


这 也 是 比较 简单 的 ， 建 立 一 个 空 接 口 IMemento 一 一 什么 方法 属性 
都 没有 的 接口 ， 然 后 在 发 起 人 Originator 类 中 建立 一 个 内 置 类 (也 叫做 
类 中 类 ) Memento 实 现 IMemento 接 口 ， 同 时 也 实现 自己 的 业务 逻辑 ， 
如 代码 清单 24-22 所 示 。 


代码 清单 24-22 发 起 人 角色 


public class Originator { 
// 内 部 状态 
private String state = ""; 
public String getState() { 
return state,; 


public void setState(String state) { 
this.state = state; 


} 
// 创 建 一 个 备 忘 3 
public IMemento createMemento(){ 
return new Memento(this. state); 


} 

// 恢 复 一 个 备忘录 

public void restoreMemento(IMemento _memento ){ 
this,setState(((Memento)_memento) ,getState() ) ，; 


} 
// 内 置 类 
private class Memento implements IMementot 
// 发 起 人 的 内 部 状态 
private String state = ""， 
// 构 造 丽 数 传递 参数 
private Memento(String _Sstate){ 
this.state = _Sstate 
} 


private String getState() { 
return state; 


private void setState(String state) { 
this.state = state,; 
} 


内 置 类 Memento 全 部 是 private 的 访问 权限 ， 也 就 是 说 除了 发 起 人 
外 ， 别 人 休想 访问 到 ， 那 如 果 要 产生 关联 关系 又 应 如 何 处 理 呢 ? 通过 
接口 ! 别 乐 记 了 我 们 还 有 一 个 空 接口 是 公共 的 访问 权限 ， 如 代码 清单 


24-23 所 示 。 


代码 清单 24-23 备忘录 的 空 接口 


public interface IMemento { 


} 


我 们 再 来 看 管理 者 ， 如 代码 清单 24-24 所 示 。 


代码 清单 24-24 备 扑 隶 管理 者 


public class 


Caretaker { 


// 和 鱼 扎 录 对 象 


private 


IMemento memento ， 


public IMemento getMemento( ) { 


return memento,; 


public void setMemento(IMemento memento) { 


this.memento = memento， 


全 部 通过 接口 访问 ， 这 当然 没有 问题 ， 如 果 你 想 访 问 它 的 属性 那 
是 肯定 不 行 的 。 但 是 安全 是 相对 的 ， 没 有 绝对 的 安全 ， 可 以 使 用 
refelect 反 射 修 改 Memento 的 数据 。 


在 这 里 我 们 使 用 了 一 个 新 的 设计 方法 双 接 口 设计 ， 我 们 的 一 个 
类 可 以 实现 多 个 接口 ， 在 系统 设计 时 ， 如 果 考 虑 对 象 的 安全 问题 ， 则 
可 以 提供 两 个 接口 ， 一 个 是 业务 的 正 第 接口 ， 实 现 必要 的 业务 逻辑 ， 
叫做 宽 接 口 ， 男 外 一 个 接口 是 一 个 空 接口 ， 什 么 方法 都 没有 ， 其 目的 
是 提供 给 子 系统 外 的 模块 访问 ， 比 如 容器 对 象 ， 这 个 叫做 罕 接 口 ， 由 
于 罕 接 口中 没有 提供 任何 操纵 数据 的 方法 ， 因 此 相对 来 说 比较 安全 。 


24.5 最 佳 实践 


备 捷 录 模 式 是 我 们 设计 上 “月 光宇 使 ”， 可 以 让 我 们 回 到 需要 的 年 
代 ; 征程 序数 据 的 “后 悔 药 ”， 号 了 它 驶 可 以 返回 上 一 个 状态 ;是 设计 
人 员 的 定心丸 ， 确 保 即 使 在 最 坏 的 情况 下 也 能 获得 最 近 的 对 象 状态 。 
如 果 大 家 看 懂 了 的 话 ， 请 各 位 在 设计 的 时 候 就 不 要 使 用 数据 库 的 临时 
表 作 为 缓存 备份 数据 了 ， 虽 然 是 一 个 简单 的 办 法 ， 但 是 它 加 大 了 数据 
库 操作 的 频 党 度 ， 把 压力 下 放 到 数据 库 了 ， 最 好 的 解决 办 法 束 是 使 用 
备 环 录 模 式 。 


第 25 章 ”访问 者 模式 
25.1 员工 的 隐私 何在 


我 们 在 前 面 讲 过 了 组 合 模 式 和 途 代 器 模式 。 通 过 组 合 模 式 能 够 把 
一 个 公司 的 人 员 组 织 机 构 树 搭建 起 来 ， 给 管理 市 来 非常 大 的 便利 ， 通 
过 适 代 融 模 式 把 每 一 个 员工 都 届 历 一 届 ， 看 看 是 不 是 “有 人 去 世 了 还 在 
领 退 休 金 ",“ 合 高 工资 而 不 干 活 的 尸 位 素 餐 ”等 情况 ， 我 们 今天 要 做 的 
束 古 把 这 些 情况 统计 成 一 个 报表 呈报 上 去 ， 让 领导 看 看 这 种 肪 务 的 情 
帝 有 多 站 重 。 


我 们 公司 有 700 名 多 拉 术 人 员 ， 分 布 在 全 国 各 地 ， 组 织 染 构 在 组 合 
模式 中 已 经 介绍 过 了 ， 是 很 肖 见 的 家 长 领导 型 模式 ， 每 个 技术 人 员 的 
科 位 都 是 固定 的 ， 你 在 组 织 机 构 的 哪 株 树 下 ， 充 当 的 角色 是 什么 ， 叶 
子 市 点 都 是 非常 明确 的 ， 每 一 个 员工 的 信息 〈 如 名 字 、 人 性别、 薪水 
等 ) 都 是 记录 在 数据 库 中 ， 现 在 有 这 样 一 个 需求 ， 我 要 把 公司 中 的 所 
有 人 员 信 息 都 打印 汇报 上 去 。 我 们 来 看 类 图 ， 如 图 25-1 所 示 。 


Employee 


-mt salary 
-String name TE 
Client -Int sex 抽象 员工 


+getter/setter salary() 
+getter/setter name() 
+getter/setter sex() 
+void report() 
#1tring getOtherInfol) 


管理 层 人 员 


SSE 本 以 


图 25-1 员工 信息 类 图 


这 个 类 图 还 古 比 较 人 简单 的 ， 我 们 定义 每 个 员工 部 有 新 水 salary、 名 
称 name、 性 别 sex 这 3 个 属性 ， 然 后 提供 了 一 个 抽象 方法 getOtherInfo 由 
子 类 进行 扩展 ， 同 时 通过 report 方 法 打印 出 每 一 个 员工 的 信息 ， 这 里 使 
用 模板 方法 模式 。 我 们 先 来 看 一 下 抽象 类 ， 如 代码 清单 25-1 所 示 。 


代码 清单 25-1 抽象 员工 


public abstract class Employee { 

public final static int MALE = 0; //0 代 表 是 男性 
public final static int FEMALE = 1; //i1 代 表 是 女性 
// 乔 管 是 谁 ， 都 有 工资 


private String name; 
// 只 要 是 员工 那 就 有 薪水 
private int salary; 
// 性 别 很 重要 
private int sex; 

// 以 下 是 简单 的 getter/setter 
public String getName() { 

return name; 


public void setName(String name) { 
this.name = name; 


} 
public int getSalary() { 
return salary; 


} 
public void setSalary(int salary) { 
this.salary = salary; 


public int getSex() { 
return sex; 


public void setSex(int sex) { 
this.sex = sex; 


} 

// 打 印 出 员工 的 信息 

public final void report(){ 
String info = "姓名 : " + this.name + "\t"; 
info = info + "性 别 : " + (this.sex == 

FEMALE?" 女 " ， " 男 ") 再 Nt" 

info = info + "薪水 : " + this.salary + "\t"; 
// 获 得 员工 的 其 他 信息 
info = info + this.getOotherIinfo(); 
System.out.println(info); 


} 
// 拼 装 员工 的 其 他 信息 
protected abstract String getotherInfo() ; 


先 看 小 兵 的 实现 类 ， 越 早 微 的 人 物 越 能 引起 共 吗 ， 因 为 我 们 有 共 
同 的 经 历 、 思 维特 难 。 请 看 实现 类 ， 如 代码 清单 25-2 所 示 。 


代码 清单 25-2 普通 员工 


public class CommonEmployee extends Employee { 
// 工 作 内 容 ， 这 非常 重要 ， 以 后 的 职业 规划 就 是 靠 它 了 
private String job; 
public String getJob() { 
return job; 


} 
public void setJob(String job) { 
this.job = job; 


} 
protected String getOtherIinfo( ){ 

return "工作 : "+ this. job + "\t"; 
} 


每 个 实现 类 都 必须 实现 getOtherInfo 信 息 ， 通 过 它 获 得 用 户 个 性 信 
妃 ， 我 们 再 来 看 管理 阶层 ， 如 代码 请 单 25-3 所 示 。 


代码 清单 25-3 管理 阶层 


public class Manager extends Employee { 
// 这 类 人 物 的 职责 非常 明确 : 业绩 
private String performance; 
public String getPerformance() { 
return performance; 


public void setPerformance(String performance) { 
this.performance = performance; 


} 
protected String getotherInfo( ){ 

return "业绩 : "+ this.performance + "Nt" 
} 


一 


Performance 这 个 单词 在 技术 人 员 的 腿 里 就 代表 性 能 ， 在 实际 两 务 
英语 中 可 以 有 Sales Performance (销售 业绩 ) 、performance evaluation 


(业绩 评估 ) 等 。 系 统 的 框架 都 已 经 具备 了 ， 那 我 们 来 模拟 一 下 这 个 
过 程 ， 如 代码 清单 25-4 所 示 。 


代码 清单 25-4 场景 


public class Client { 
public static void main(String[] args) { 


} 


// 模 拟 H 


for(Employee emp:mockEmployee())t{ 
emp.report(); 
} 


公司 的 人 员 情 况 ， 我 们 可 以 想象 这 个 数据 是 通过 持久 层 传递 过 来 的 


public static List<Employee> mockEmployee( ){ 


ng 


List<Employee> empList = new ArrayList<Employee>(); 
// 产 生 张 三 这 个 员工 

CommonEmployee zhangSan = new CommonEmployee( ); 
zhangSan.setJob( "编写 Java 程 序 ， 绝 对 的 蓝领 、 蔡 工 加 搬运 


zhangSan,setName(" 张 三 ") ， 
zhangSan.setSalary(1800); 
zhangSan.setSex(Employee .MALE); 
empList.add(zhangSan); 

// 产 生 李 四 这 个 员工 

CommonEmployee 1iSi = new CommonEmployee(); 
liSsi.setJob(" 页 面 美工 ， 审 美 素质 太 不 流行 了 ! " ) ; 
lisi.setName(" 李 四 ")，; 

1iSi.setSalary(1900); 
1iSi.setSex(Employee.FEMALE); 
empList.add(1iSi); 

// 再 产生 一 个 经 理 

Manager wangWu = new Manager(); 

wangWwu .setName(" 王 五 " ); 

wangwu .setPerformance(" 基 本 上 是 负 值 ， 但 是 我 会 拍马屁 呀 "); 
wangwu.setSalary(18750); 
wangwu.setSex(Employee .MALE); 
empList.add(wangWwu ) ， 

return empList 


先 通 过 mockEmployee 来 模拟 出 一 个 数组 ， 初 始 化 两 个 员工 和 一 个 
经 理 ， 当 然 在 实际 项 目 中 这 个 数组 应 该 由 持久 层 产 生 。 运 行 结果 如 下 


性 


新 水 ， ”工作 : 编写 Java 程 序 ， 绝 对 的 蓝领 、 


张 三 别 : 男 1800 问 工 加 搬运 工 

姓名 : 性 薪水 : 工作 : 页面 美工 ， 审 美 素质 太 不 流行 
李 四  ” 别 : 女 1900 下 

姓名 : 性 薪水 : 业绩 : 基本 上 是 负 值 ， 但 是 我 会 拍 马 
王 五 ” 别 : 男 18750 屁 呀 


结 采 出 来 了 ， 非 党 正确 。 我 们 来 想 一 想 实 际 的 情况 ， 人 力 资 源 部 
门 拿 这 份 表格 会 给 谁 看 呢 ? 那 当然 是 大 老板 了 ! 大 老板 关心 的 是 什 
么 ? 关心 部 门 经 理 的 业绩 ! 小 兵 的 情况 不 是 他 要 了 人 解 的 ， 避 ® 像 战争 时 
期 一 位 将 军 说 :“ 我 一 想到 我 的 士兵 也 有 护 子 、 妻 子 、 父 母 ， 我 工 痛心 
疾 下 .….. 但 古 这 是 战场 ， 我 只 能 认为 他 们 是 一 群 机 右 .…...” 古 啊 ， 其 实 
我 们 也 一 样 啊 ， 那 问题 束 出 来 了 : 


e 大 老板 束 看 部 门 经 理 的 报表 ， 小 兵 的 报表 可 看 可 不 看 。 


e 多 个 大 老板 的 “嗜好 ?十 不 同 的 ， 主 管 销售 的 ， 则 主要 关心 萌 销 的 
情况 ; 主管 会 计 的 ， 则 主要 关心 企业 的 整体 财务 运行 状态 ;主管 技术 
的 ， 则 主要 看 技术 的 人 研发 情况 。 


综合 成 一 句 话 ， 这 个 报表 会 修改 : 数据 的 修改 以 及 报表 的 展现 修 
改 ， 按 照 开 闭 原则 ， 项 目 分 析 的 时 候 已 经 考虑 到 这 些 可 能 引起 变更 的 
因素 ， 束 需要 在 设计 时 考虑 通过 扩展 来 避 开 未 来 需求 变更 而 引起 的 代 
码 修改 风险 。 我 们 来 想 一 想 ， 每 个 普通 员工 类 和 经 理 类 都 用 一 个 方法 
report (从 父 类 继承 过 来 的 ) ， 他 无 法 为 每 一 个 子 类 定制 特殊 的 属性 ， 
人 简化 类 图 如 图 25-2 所 示 。 


上 Employee 


+Vold report() 


让 


Manager 


CommonEmployee 


图 25-2 简化 类 图 


我 们 思考 一 下 ， 如 何 提供 一 个 能 够 为 每 个 子 类 定制 报表 的 方法 
呢 ? 可 以 这 样 思考 ， 普 通 员 工 和 管理 层 员 工 是 两 个 不 同 的 对 象 ， 例 
如 ， 我 邀请 一 个 人 过 来 参观 我 的 家 ， 参 观 者 参观 完毕 后 分 别 进 行 描 
述 ， 那 参观 的 对 象 不 同 ， 描 述 的 结果 也 当然 不 同 。 好 ， 按 照 这 思路 ， 
我 们 把 方法 report 提 取 到 另外 一 个 类 Visitor 中 来 实现 ， 如 图 25-3 所 示 。 


CommonEmployee Manager 


Visitor 


+Vold report() 


图 25-3 改造 后 的 简化 类 图 


两 个 子 类 的 report 方 法 都 不 需要 了 ， 只 有 Visitor 类 来 实现 了 report 的 
方法 ， 这 个 猛 一 看 还 真有 点 委托 (intergration) 的 意味 ， 我 们 实现 出 来 
你 就 知道 这 和 委托 有 非常 大 的 差距 。 详 细 类 图 如 图 25-4 所 示 。 


<<interface>> 
IVisitor 


tvisit(CommonEmployee commonEmployee) 
+Void vist(Manager manager) 


Client 


ee ; Wiltor 
| 沪 问 者 | . 
Employee 


-int salary 
-String name 
-int sex 


rgetter/setter salary() 
rpgetter/setter name() 
tgetter/setter sex() 

+vold report() 

+void accept(/IVisitor visitor) 


-Strng performance 


CommonEmployee 


-String job 


+getter/setter job() +getter/setter pertormance() 


图 25-4 改造 后 的 评 细 类 图 


在 抽象 类 Employee 中 增加 了 accept 方 法 ， 该 方法 是 一 个 抽象 方法 ， 
由 子 类 实现 ， 其 意义 就 是 说 我 这 个 类 可 以 允许 谁 来 访问 ， 也 就 是 定义 
一 类 访问 者 ， 在 具体 的 实现 类 中 调用 访问 者 的 方法 。 我 们 先 看 访问 者 
接口 TVisitor 程 序 ， 如 代码 清单 25-5 所 示 。 


代码 清单 25-5 访问 者 接口 


public interface IVISTEOr { 
// 首 先 ， 定义 我 可 以 访问 普通 员工 
public void visit(CommonEmployee commonEmployee); 
// 其 次 ， 定义 我 还 可 以 访问 部 门 经 理 
public void visit(Manager manager ); 


该 接口 的 意义 是 : 该 接口 可 以 访问 两 个 对 象 ， 一 个 是 普通 员工 ， 
一 个 是 高 层 员 工 。 我 们 来 看 其 具体 实现 类 ， 如 代码 清单 25-6 所 示 。 


代码 清单 25-6 访问 者 实现 


public class Visitor implements IVisitor { 
// 访 问 普 通 员工 ， 打 印 出 报表 
public void visit(CommonEmployee commonEmployee) { 


System.out.println(this.getCommonEmployee(commonEmployee)); 


} 

// 访 问 部 门 经 理 ， 打 印 出 报表 

public void visit(Manager manager) { 
System.out.println(this.getManagerIinfo(manager ) ) ; 


} 
// 组 装 出 基本 信息 
private String getBasicIinfo(Employee employee)t{ 
String info = "姓名 : " + employee.getName() + "\t"; 
info = info + "性 别 : " + (employee.getSex() == 
Employee.FEMALE?" 女 ":" 男 ") + "\t"，; 
info = info + "薪水 : " + employee.getSalary() + 


NCS 
return info; 


} 
// 组 装 出 部 门 经 理 的 信息 
private String getManagerInfo(Manager manager ){ 
String basicInfo = this.getBasicInfo(manager ) ; 
String otherInfo = "业绩 : "+manager ,getPerformance( ) 


十 RN 二 人 
了 
return basicInfo + otherInfo ， 


} 
// 组 装 出 普通 员工 信息 
private String getCommonEmployee(CommonEmployee 


commonEmployee)t{ 
String basicInfo = 
this.getBasicInfo(commonEmp1Loyee ) ， 
String otherInfo = "I 
作 : "+commonEmployee.getJob()+"\t"， 
return basicInfo + otherInfo， 
} 


在 具体 的 实现 类 中 ， 定 义 了 两 个 私有 方法 ， 作 用 了 就 是 产生 需要 打 
印 的 数据 和 格式 ， 然 后 在 访问 者 访问 相关 的 对 象 时 产生 这 个 报表 。 抽 
象 员 工 Employee 稍 有 修改 ， 如 代码 清单 25-7 所 示 。 


代码 清单 25-7 抽象 员工 类 


public abstract class Employee { 
public final static int MALE = 0; //0 代 表 
public final static int FEMALE = 1; //1 代 靶 
// 乔 管 是 谁 ， 都 有 工资 
private String name; 
// 只 要 是 员工 那 就 有 薪水 
private int salary; 
// 性 别 很 重要 
private int sex; 
// 以 下 是 简单 的 getter/setter 
public String getName() { 

return name; 


"| 


public void setName(String name) { 
this.name = name; 


} 
public int getSalary() { 
return salary; 


} 
public void setSalary(int salary) { 
this.salary = salary; 


} 
public int getSex() { 
return sex; 


public void setSex(int sex) { 
this.sex = sex; 


// 我 允许 一 个 访问 者 访问 


public abstract void accept(IVisitor Visitor ) 
抽象 员工 类 有 3 个 变动 : 
e 删除 了 report 方 法 。 


e 增加 了 accept 方 法 ， 接 受 访 问 者 的 访问 。 


e 删除 了 getOtherInfo 方 法 。 它 的 实现 由 访问 着 来 处 理 ， 因 为 访问 
者 对 被 访问 的 对 象 是 “ 心 知 肚 明 ”的 ， 非 常 了 解 被 访问 者 。 


我 们 继续 来 看 员工 实现 类 ， 普 通 员工 代 码 清单 25-8 所 示 。 


代码 清单 25-8 普通 员工 


public class CommonEmployee extends Employee { 
// 工 作 内 容 ， 这 非常 重要 ， 以 后 的 职业 规划 就 是 靠 它 了 
private String job; 
public String getJob() { 
return job; 


} 
public void setJob(String job) { 
this.job = job; 


} 

// 我 允许 访问 者 访问 

Q@override 

public void accept(IVisitor visitor)t{ 
visitor.visit(this); 

} 


上 面 是 普通 员工 的 实现 类 ， 该 类 的 accept 方 法 很 简单 ， 这 个 类 就 把 
自身 传递 过 去 ， 也 残 是 让 访问 者 访问 本 号 这 个 对 象 。 再 看 Manager 类 ，， 


如 代码 清单 25-9 所 示 。 


代码 清单 25-9 管理 层 员工 


public class Manager extends Employee { 
// 这 类 人 物 的 职责 非常 明确 : 业绩 
private String performance; 
public String getPerformance() { 
return performance; 


public void setPerformance(String performance) { 
this.performance = performance; 


} 

// 部 门 经 理 允许 访问 者 访问 

Q@Override 

public void accept(IVisitor visitor)t{ 
visitor.visit(this); 

} 


所 有 的 业务 定义 都 已 经 完成 ， 我 们 来 看 看 怎么 模拟 这 个 逻辑 ， 如 
代码 清单 25-10 所 示 。 


代码 清单 25-10 场景 类 


public class Client { 
public static void main(String[] args) { 
for(Employee emp:mockEmployee())t{ 
emp.accept(new Visitor()) 
} 


} 

// 模 拟 出 公司 的 人 员 情 况 ， 我 们 可 以 想象 这 个 数据 是 通过 持久 层 传递 过 来 的 
public static List<Employee> mockEmployee( ){ 
List<Employee> empList = new ArrayList<Employee>(); 
// 产 生 张 三 这 个 员工 

CommonEmployee zhangSan = new CommonEmployee( ); 
zhangSan.setJob( "编写 Java 程 序 ， 绝 对 的 蓝领 、 蔡 工 加 搬运 


了 


4 
zhangSan.setName(" 张 三 ")，; 
zhangSan. setSalary(1800); 
zhangSan.setSex(Employee .MALE); 


empList,add(zhangSan) 

// 产 生 李 四 这 个 员工 

CommonEmployee 1iSi = new CommonEmployee(); 
liSsi.setJob(" 页 面 美工 ， 审 美 素质 太 不 流行 了 ! ") ; 
1iSi,.setName(" 李 四 " )， 

1iSi.setSalary(1900); 
1iSi.setSex(Employee.FEMALE); 
empList.add(1iSi); 

// 再 产生 一 个 经 理 

Manager wangWu = new Manager(); 
wangwu.setName(" 王 五 ") ; 

wangwu .setPerformance(" 基 本 上 是 负 值 ， 但 是 我 会 拍马屁 呀 "); 
wangWwu.setSalary(18750); 
wangwu.setSex(Employee .MALE); 
empList.add(wangWwu ) ， 

return empList 


改动 非 甫 少 ， 束 黑体 那么 一 行 的 改动 ， 运 行 结 来 如 下 : 


姓名 : 性 薪水 : 工作 : 编写 Java 程 序 ， 绝 对 的 蓝领 、 
张 三 别 : 男 1800 吾 工 加 搬运 工 

姓名 : 性 薪水 : 工作 : 页 面 美工 ， 审 美 素质 太 不 流行 
李 四  ” 别 : 女 1900 " 

姓名 : 性 薪水 : 业绩 : 基本 上 是 负 值 ， 但 是 我 会 拍 马 
王 五 ” 别 : 男 18750 


运行 结果 也 完全 相同 ， 那 回 过 头 来 看 看 这 个 程序 是 怎么 实现 的 : 
。 第 一 ， 通 过 循环 志 历 所 有 元 素 。 
e 第 二 ， 每 个 员工 对 象 都 定义 了 一 个 访问 者 。 


e 第 三 ， 员 工 对 象 把 自己 作为 一 个 参数 调用 访问 者 visit 方 法 。 


e 第 四 ， 访 问 者 调用 目 己 内 部 的 计算 逻辑 ， 计 算出 相应 的 数据 和 表 
格 元 素 。 


e 第 了 五， 访问 着 打印 出 报表 和 数据 。 


事情 的 经 过 束 是 这 个 样子 。 那 我 们 再 来 看 看 上 面 拓 到 的 数据 和 报 
表格 式 都 会 改变 的 情况 。 首 先是 数据 的 改变 ， 数 据 改 了 当然 都 要 改 ， 
说 不 上 两 个 方案 有 什么 优 务 ， 其 次 是 报表 格式 的 修改 ， 这 个 方案 绝对 
是 有 优势 的 ， 我 只 要 再 产生 一 个 IVisitor 的 实现 类 就 可 以 产生 一 个 新 的 
报表 格式 ， 而 其 他 的 类 都 不 用 修改 ， 如 琳 你 用 Spring 开 发 ， 那 束 更 好 
了 ， 在 Spring 的 配置 文件 中 使 用 的 是 接口 注入 ， 我 只 要 把 配置 文件 中 的 
ref 修 改 一 下 束 行 了 ， 其 他 的 都 不 用 修改 了 ! 这 就 古 访问 着 模式 的 优势 
所 在 。 


25.2 访问 者 模式 的 定义 


访问 者 模式 (Visitor Pattern) 是 一 个 相对 简单 的 模式 ， 其 定义 如 
下 : Represent an operation to be performed on the elements of an object 
structure. Visitor lets you define a new operation without changing the 
classes of the elements on which it operates. (封装 一 些 作 用 于 某 种 数据 
结构 中 的 各 元 聚 的 操作 ， 它 可 以 在 不 改变 数据 结构 的 前 提 下 定义 作用 
于 这 些 元 素 的 新 的 操作 。) 


访问 者 模 式 的 通用 类 图 如 图 25-5 所 示 。 
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图 25-5 访问 者 模式 的 通用 类 图 


看 了 这 个 通用 类 图 ， 大 家 可 能 要 犯 迷糊 了 ， 这 里 起 么 有 一 个 
ObjectStruture 类 昵 ?你 刚刚 举 的 例子 怎么 束 没 有 呢 ? 真 没有 吗 ? 我 们 
不 是 定义 了 一 个 List 了 上 吗 ? 它 中 间 的 元 素 是 我 们 一 个 一 个 手动 增加 上 去 
的 ， 这 就 是 一 个 ObjectStruture， 我 们 来 看 这 几 个 角色 的 职责 。 


抽象 访问 者 


@ Visitor 


抽象 类 或 者 接口 ， 声 明 访问 者 可 以 访问 哪些 元 素 ， 有 具体 到 程序 中 
就 是 visit 方 法 的 参数 定义 哪些 对 象 是 可 以 被 访问 的 。 


e@ ConcreteVisitor 具体 访问 者 


它 影 啊 访 问 痢 访问 到 一 个 类 后 该 怎么 干 ， 要 做 什么 事情 。 


抽象 元 到 


ee Element 


接口 或 者 抽象 类 ， 声 明 接 受 哪 一 类 访问 者 访问 ， 程 序 上 是 通过 
accept 方 法 中 的 参数 来 定义 的 。 


具体 元 素 


@ ConcreteElement 


实现 accept 方 法 ， 通 常 是 visitor.visit(this)， 基 本 上 都 形成 了 一 种 模 
ed 


结构 对 象 


e ObjectStruture 


元 素 产 生 者 ， 一 般 容 纳 在 多 个 不 同类 、 不 同 接口 的 容器 ， 如 List、 
Set、Map 等 ， 在 项 目 中 ， 一 般 很 少 抽象 出 这 个 角色 。 


大 家 可 以 这 样 理解 访问 者 模式 ， 我 作为 一 个 访客 (Visitor) 到 朋友 
家 (Visited Class) 去 拜访 ， 朋 友之 间 聊 聊天 ， 喝 喝酒 ， 再 相互 吹捧 吹 
捧 ， 炫 净 炫 次， 这 都 正常 。 聊 天 的 时 候 ， 朋 友 告 诉 我 ， 他 今年 加 官 亚 
风 了， 工资 也 涨 了 30%， 准 备 再 买 套 房子 ， 那 我 束 在 心里 表 算 (Visitor- 
self-method)“ 你 这 么 有 钱 ， 我 去 年 要 借 10 万 你 都 不 借 ”"， 我 根据 朋友 的 
信息 ， 执 行 了 自己 的 一 个 方法 。 


我 们 来 看 看 访问 者 模式 的 通用 源码 ， 先 看 抽象 元 素 ， 如 代码 清单 
25-11 所 示 。 


代码 清单 25-11 抽象 元 素 


public abstract class Element { 
// 定 义 业 务 逻 辑 
public abstract void doSomething(); 
// 人 允许 谁 来 访问 


public abstract void accept(IVisitor Visitor ) 


抽象 元 素 有 两 类 方法 : 一 是 本 喘 的 业务 逻辑 ， 也 就 古 元 素 作 为 一 
个 业务 处 理 单 元 必须 完成 的 职责 ; 丈 外 一 个 是 允许 哪 一 个 访问 者 来 访 
问 。 我 们 来 看 具体 元 素 ， 如 代码 请 单 25-12 所 示 。 


代码 清单 25-12 具体 元 素 


public class ConcreteElement1 extends Element{ 
// 完 善 业务 逻辑 
public void doSomething(){ 
// 业 务 处 理 


} 

// 人 允许 那个 访问 者 访问 

public void accept(IVisitor visitor)t{ 
visitor.visit(this); 

} 


public class ConcreteElement2 extends Element{ 
// 完 善 业务 逻辑 
public void doSomething(){ 
// 业 务 处 理 


} 

// 人 允许 那个 访问 者 访问 

public void accept(IVisitor visitor)t{ 
visitor.visit(this); 

} 


它 定 义 了 两 个 具体 元 素 ， 我 们 再 来 看 抽象 访问 者 ， 一 般 是 有 几 个 
具体 元 素 束 有 几 个 访问 方法 ， 如 代码 清单 25-13 所 示 。 


代码 清单 25-13 抽象 访问 者 


public interface IVisitor { 
// 可 以 访问 哪些 对 象 
public void visit(ConcreteElement1 el1); 
public void visit(ConcreteElement2 el12); 


具体 访问 者 如 代码 清单 25-14 所 示 。 


代码 清单 25-14 具体 访问 者 


public class Visitor implements IVisitor { 
// 访 问 el11 元 素 
public void visit(ConcreteElement1 el1) { 
el1i.doSomething( ); 


} 

// 访 问 e12 元 素 

public void visit(ConcreteElement2 el2) { 
el2.doSomething( ); 

} 


结构 对 象 是 产生 出 不 同 的 元 素 对 象 ， 我 们 使 用 工厂 方法 模式 来 模 
拟 ， 如 代码 清单 25-15 所 示 。 


代码 清单 25-15 结构 对 象 


public class ObjectStruture { 
// 对 象 生 成 器 ， 这 里 通过 一 个 工厂 方法 模式 模拟 
public static Element createElement(){ 
Random rand = new Random( ) ; 
if(rand.nextInt(100) > 50){ 
return new ConcreteElement1(); 


}elsef 


} 


return new ConcreteElement2( ) ; 


进入 了 访问 着 角色 后 ， 我 们 对 所 有 的 具体 元 素 的 访问 束 非 常人 简单 
了 ， 我 们 通过 一 个 场景 类 模拟 这 种 情况 ， 如 代码 清单 25-16 所 示 。 


代码 清单 25-16 场景 类 


public class Client { 
public static void main(String[] args) { 
for(int i=0;i<10;i++){ 
// 获 得 元 素 对 象 
Element el = 
ObjectStruture.createElement(); 
// 接 受 访 问 者 访问 
el.accept(new Visitor()); 


通过 增加 访问 着 ， 只 要 是 具体 元 素 束 非 第 容易 访问 ， 对 元 到 的 遍 
历 就 更 加 容易 了 ， 和 看 管 它 是 什么 对 象 ， 只 要 它 在 一 个 容器 中 ， 都 可 以 
通过 访问 者 来 访问 ， 任 务 集中 化 。 这 融 是 访问 者 模式 。 


25.3 访问 者 模式 的 应 用 
25.3.1 访问 着 模式 的 优点 


e 符合 单一 职责 原则 


具体 元 素 角 色 也 蝶 古 Employee 抽 象 类 的 两 个 子 类 人 负责 数据 的 加 
载 ， 而 Visitor 类 则 人 负责 报表 的 展现 ， 两 个 不 同 的 职责 非常 明确 地 分 离 
开 来 ， 各 目 演 绎 变化 。 


e 优秀 的 扩展 性 


由 于 职责 分 开 ， 继 续 增 加 对 数据 的 操作 是 非常 快捷 的 ， 例 如 ， 现 
在 要 增加 一 份 给 大 老板 的 报表 ， 这 份 报表 格式 又 有 所 不 同 ， 直 接 在 
Visitor 中 增加 一 个 方法 ， 传 递 数据 后 进行 整理 打印 。 


e 灵活 性 非常 高 


例如 ， 数 据 汇总 ， 就 以 刚刚 我 们 说 的 Employee 的 例子 ， 如 果 我 现 
在 要 统计 所 有 员工 的 工资 之 和 ， 怎 么 计算 ? 把 所 有 人 的 工资 for 循 环 加 
一 遍 ? 是 个 办 法 ， 那 我 再 提 个 问题 ， 员 工 工资 x1.2， 部 门 经 理 x1.4， 
尽 经 理 x1.8， 然 后 把 这 些 工资 加 起 来 ， 你 怎么 处 理 ? 1.2，1.4，1.8 是 
什么 ? 不 是 吧 ? ! 你 没 看 到 领导 不 论 什 么 时 候 都 比 你 拿 得 多 ， 工 资 奖 


金 束 不 说 了 ， 束 是 过 节 发 个 慰问 券 也 比 你 多 ， 束 是 这 个 系数 在 作 肉 。 
我 们 继续 说 你 想 怎 么 统计 ? 使 用 for 循 环 ， 然 后 使 用 instanceof 来 判断 是 

员工 还 是 经 理 ? 这 可 以 解决 ， 但 不 是 个 好 办 法 ， 好 办 法 是 通过 访问 者 
模式 来 实现 ， 把 数据 扔 给 访问 者 ， 由 访问 者 来 进行 统计 计算 。 


25.3.2 访问 者 模式 的 缺点 


e 具体 元 素 对 访问 者 公布 细 市 

访问 者 要 访问 一 个 类 束 必 然 要 求 这 个 类 公布 一 些 方法 和 数据 ， 也 
束 是 说 访问 者 关注 了 其 他 类 的 内 部 细 广 ， 迪 米 特 法 则 所 不 建议 
的 。 


e 具体 元 素 变更 比较 困难 


具体 元 素 角色 的 增加 、 删 除 、 修 改 都 是 比较 困难 的 ， 融 上 面 那个 
例子 ， 你 想 想 ， 你 要 坪 想 增加 一 个 成 员 变 量 ， 如 年 龄 age，Visitor 残 需 
要 修改 ， 如 有 果 Visitor 是 一 个 还 好 办 ， 多 个 呢 ? 业务 逻辑 再 复杂 点 呢 ? 


违 育 了 依赖 倒置 转 原 则 


访问 者 依赖 的 是 具体 元 素 ， 而 不 是 抽象 元 素 ， 这 破坏 了 依赖 倒置 
原则 ， 特 别 是 在 面向 对 象 的 编程 中 ， 抛 弃 了 对 接口 的 依赖 ， 而 直接 依 
赖 实现 类 ， 扩 展 比较 难 。 


25.3.3 访问 着 模式 的 使 用 场景 


e 一 个 对 象 结构 包含 很 多 类 对 象 ， 它 们 有 不 同 的 接口 ， 而 你 想 对 
这 些 对 象 实施 一 些 依赖 于 其 具体 类 的 操作 ， 也 就 说 古 用 磊 代 器 模式 已 
经 不 能 胜任 的 情景 。 


。 需 要 对 一 个 对 象 结构 中 的 对 象 进行 很 多 不 同 并 且 不 相关 的 操 
作 ， 而 你 想 避 免 让 这 些 操作 “污染 "这 些 对 象 的 类 。 


总 结 一 下 ， 在 这 种 地 方 你 一 定 要 考虑 使 用 访问 者 模式 ， 业 务 规则 
要 求 表 历 多 个 不 同 的 对 象 。 这 本 和 映 也 是 访问 者 模式 出 发 点 ， 和 代 器 模 
式 只 能 访问 同类 或 同 接口 的 数据 (当然 了 ， 如 采 你 使 用 instanceof， 那 
么 能 访问 所 有 的 数据 ， 这 没有 争论) ， 而 访问 者 模式 是 对 迭代 大 模式 
的 扩充 ， 可 以 过 历 不 同 的 对 象 ， 然 后 执行 不 同 的 操作 ， 也 束 古 针对 访 
问 的 对 象 不 同 ， 执 行 不 同 的 操作 。 访 问 者 模式 还 有 一 个 用 途 ， 束 是 充 
当 拦截 器 (Interceptor) 角色 ， 这 个 我 们 将 在 混 编 模式 中 讲解 。 


25.4 访问 者 模式 的 扩展 


访问 者 模式 是 经 芝 用 到 的 模式 ， 虽 然 你 不 注意 ， 有 可 能 你 起 的 名 
字 也 不 十 什么 Visitor， 但 是 它 确实 古 非 常 容易 使 用 到 的 ， 在 这 里 我 提出 
两 个 扩展 的 功能 供 大 家 参考 。 


25.4.1 统计 功能 


在 例子 中 我 们 也 提 到 访问 者 的 统计 功能 ， 汇 总 和 报表 是 金融 类 企 
业 非 常常 用 的 功能 ， 基 本 上 都 是 一 堆 的 计算 公式 ， 然 后 出 一 个 报表 ， 
很 多 项 目 采 用 了 数据 库 的 存储 过 程 来 实现 ， 我 不 是 很 推荐 这 种 方式 ， 
除非 海量 数据 处 理 ， 一 个 晚上 要 批 处 理 上 亿 、 几 十 亿 条 的 数据 ， 除 了 
存储 过 程 来 处 理 还 没有 其 他 办 法 ， 你 要 是 用 应 用 服务 器 来 处 理 ， 连 接 
数据 库 的 网 络 就 是 处 于 100% 占 用 状态 ， 一 个 晚上 也 未 必 能 处 理 完 这 批 
数据 ! 除了 这 种 海量 数据 外 ， 我 建议 数据 统计 和 报表 的 批 处 理 通 过 访 
问 者 模式 来 处 理会 比较 简单 。 好 ， 那 我 们 来 统计 一 下 公司 人 员 的 工资 
尽 额 ， 先 看 类 图 ， 如 图 25-6 所 示 。 


<<interface>> 
IVisitor 


t+visit(CommonEmployee commonEmployee) 
t+void visit(Manager manager) 
+int getTotalSalary() 


访问 者 Visitor 
Employee 


-Int salary 
-String name 
-Int sex 


ji: 


+getter/setter salary() 
+getter/setter name() 
tgetter/setter sex() 

+vold report() 

Hvoid accept(IVisitor visitor) 


-String performance 


CommonEmployee 


-String job 


| 


+tgetter/setter job() +getter/setter performance( 


图 25-6 统计 功能 的 访问 考 模式 


没什么 变化 ? 仔细 看 IVisitor 接 口 ， 增 加 了 一 个 getTotalSalary 方 法 ， 
在 Visitor 实 现 类 中 实现 该 方法 。 我 们 先 看 接口 ， 如 代码 清单 25-17 所 


尔 。 


代码 清单 25-17 抽象 访问 者 


public interface IVisitor { 
// 首 先 定 义 我 可 以 访问 普通 员工 
public void visit(CommonEmployee commonEmployee); 
// 其 次 定义 ， 我 还 可 以 访问 部 门 经 理 
public void visit(Manager manager ); 
// 统 计 所 有 员工 工资 总 和 
public int getTotalSalary(); 


这 束 多 了 一 个 getTotalSalary 方 法 。 我 们 再 来 看 实现 类 ， 如 代码 清单 
25-18 所 示 。 


代码 清单 25-18 具体 访问 者 


public class Visitor implements IVisitor { 
// 部 门 经 理 的 工资 系数 是 5 
private final static int MANAGER_COEFFICIENT = 5; 
// 员 工 的 工资 系数 是 2 
private final static int COMMONEMPLOYEE COEFFICIENT = 2; 
// 普 通 员 工 的 工资 总 和 
private int commonTotalSalary = 0; 
// 部 门 经 理 的 工资 总 和 
private int managerTotalSalary =0; 
// 计 算 部 门 经 理 的 工资 总 和 
private void calManagerSalary(int salary)t{ 
this.managerTotalSalary = this.managerTotalSalary + 


salary 
*MANAGER_COEFFICIENT ， 


} 

// 计 算 普 通 员工 的 工资 总 和 

private void calCommonSlary(int salary)t{ 
this.commonTotalSalary = this.commonTotalSalary + 
salary*COMMONEMPLOYEE_ COEFFICIENT; 


} 
// 获 得 所 有 员工 的 工资 总 和 
public int getTotalSalary(){ 
return this.commonTotalSalary + 
this.managerTotalSalary; 


} 
有 


员工 和 经 理 层 的 信息 束 不 再 展示 了， 请 参考 代码 清单 25-6。 程 序 还 
是 比较 简单 的 ， 分 别 计算 普通 员工 和 经 理 级 员工 的 工资 总 和 ， 然 后 加 
起 来 。 注 意 ， 我 们 在 实现 时 已 经 考虑 员工 工资 和 经 理工 资 的 系数 不 
同 O 


我 们 再 来 看 Client 类 的 模拟 ， 如 代码 清单 25-19 所 示 。 


代码 清单 25-19 场景 


public class Client { 
public static void main(String[] args) { 
IVisitor visitor = new Visitor() 
for(Employee emp:mockEmployee( )) 
emp.accept(visitor); 


{ 


System.out.println(" 本 公司 的 月 工资 总 额 
是 : "+Visitor.getTotalsalary()); 


} 
其 中 mockEmployee 静 态 方 法 没有 任何 改动 ， 请 参考 代码 消音 25- 
10， 在 此 不 再 袭 述 。 运 行 结 果 如 下 所 示 : 


姓名 : 性 薪水 : 工作 : 编写 Java 程 序 ， 绝 对 的 蓝领 、 


张 三 “ 别 : 男 1800 问 工 加 搬运 工 
姓名 : 性 薪水 : 工作 : 页 面 美工 ， 审 美 素质 太 不 流行 
李 四 别 : 女 1900 | 


姓名 : 性 薪水 : 业绩 : 基本 上 是 负 值 ， 但 是 我 会 招 马 
王 五 ” 别 : 男 18750 屁 呀 


本 公 可 | 的 有 工资 总 额 是 : 101150 


然后 你 想 修改 工资 的 系数 ， 没 有 问题 ! 想 换 个 展示 格式 ， 也 没有 


问题 ! 多 多 练习 吧 ， 这 都 是 非常 简单 的 。 


25.4.2 多 个 访问 者 


在 实际 的 项 目 中 ， 一 个 对 象 ， 多 个 访问 者 的 情况 非常 多 。 其 实 我 
们 上 面 例子 就 应 该 是 两 个 访问 者 ， 为 什么 呢 ? 报表 分 两 种 ， 第 一 种 是 
展示 表 ， 通 过 数据 库 查 询 ， 把 结 琳 展示 出 来 ， 这 个 就 类 似 于 我 们 的 那 
个 列表 ;第 二 种 是 汇总 表 ， 这 个 是 需要 通过 模型 或 者 公式 计算 出 来 
的 ,一般 都 是 批 处 理 结果 ， 这 个 类 似 于 我 们 计算 工资 忌 额 ， 这 两 种 报 
表格 式 是 对 同一 堆 数 据 的 两 种 处 理 方 式 。 从 程序 上 看 ， 一 个 类 就 有 个 
不 同 的 访问 者 了 。 修 改 一 下 类 图 ， 如 图 25-7 所 示 。 


类 图 看 着 挺 复杂 ， 其 实 也 没什么 复杂 的 ， 只 是 多 了 两 个 接口 和 两 
个 实现 类 ， 分 别 负责 展示 表 和 汇总 表 的 业务 处 理 ，IVisitor 接 口 没 有 改 
变 ， 请 参考 代码 清单 25-5 所 示 代码 ， 这 里 不 再 痪 述 。 我 们 来 看 展示 报表 
接口 ， 如 代码 清单 25-20 所 示 。 


代码 清单 25-20 展示 表 接 口 


public interface IShowVisitor extends IVisitor { 
// 展 示 报 表 
public void report(); 


展示 表 的 实现 也 比较 人 简单， 如 代码 清单 25-21 所 示 。 


代码 清单 25-21 具体 展示 表 


public class ShowVisitor implements IShowVisitor { 
private String info = ""; 
// 打 印 出 报表 
public void report() { 
System.out.println(this.info); 


} 
// 访 问 普 通 员工 ， 组 装 信 息 
public void ee commonEmployee) { 
this.info = this.info + 
this.getBasicIinfo(commonEmployee) 
+ "工作 : "+commonEmployee.getJob()+"\t\n"; 


} 
// 访 问 经 理 ， 然 后 组 装 信 息 
public void visit(Manager manager) { 

this.info = this.info + this.getBasicIinfo(manager) + 


"业绩 ; 
"+manager ,getPerformance() + "\t\n"; 


} 
// 组 装 出 基本 信息 
private String getBasicInfo(Employee employee)t{ 
String info = "姓名 : " + employee.getName() + | 
info = info + "性 别 : " + (employee.getSex() = 
Employee.FEMALE?" 女 ": 
" 男 ") + NE 
info = info + "薪水 : " + employee.getSalary() + "\t"; 
return info; 


<<interface>> 
IVisitor 
CE 


+vist(CommonEmployee commonEmployee) 
+vold visit(Manager manager) 


<<mterface>> 
ITotalVisitor | 
| 


<<interface>> 
IShowVisitor 


+void report() 


人 


+void totalSalary() 


Emplovee 


-int salary 
-String name 
-int sex 


+getter/setter salary() 
+getter/setter name() 
+getter/setter sex() 

+void report() 

+void accept(IVisitor visitor) 


图 25-7 多 访问 者 的 类 图 


汇总 表 实 现 数据 汇总 功能 ， 其 接口 如 代码 清单 25-22 所 示 。 


代码 清单 25-22 汇总 表 接 口 


public interface ITotalVisitor extends IVisitor { 
/统计 所 有 员工 工资 总 和 
public void totalSalary(); 


束 一 句 话 ， 非 常人 简单 ， 我 们 再 来 看 具体 的 汇 忌 表 访 问 者 ， 如 代码 
清单 25-23 所 示 。 


代码 清单 25-23 具体 汇总 表 


public class TotalVisitor implements ITotalVisitor { 
// 部 门 经 理 的 工资 系数 是 5 
private final static int MANAGER_ COEFFICIENT = 5; 
// 员 工 的 工资 系数 是 2 
private final static int COMMONEMPLOYEE COEFFICIENT = 2; 
// 普 通 员工 的 工资 总 和 
private int commonTotalSalary = 
// 部 门 经 理 的 工资 总 和 
private int managerTotalSalary =0; 
public void totalSalary() { 
System,.out .println(" 本 公司 的 月 工资 总 额 是 " + 
(this.commonTotalSalary + 
this.managerTotalSalary)); 


} 
// 访 问 普 通 员 工 ， 计 算 工 资 总 额 
public void visit(CommonEmployee commonEmployee) { 
this.commonTotalSalary = this.commonTotalSalary + 
commonEmployee.getSalary() *COMMONEMPLOYEE COEFFICIENT; 


} 
// 访 问 部 门 经 理 ， 计 算 工 资 总 额 
public void visit(Manager manager) { 
this.managerTotalSalary = this.managerTotalSalary + 
manager .getSalary() *MANAGER_ COEFFICIENT ; 
} 


最 后 看 我 们 的 场景 类 如 何 计算 出 工资 总 额 ， 如 代码 清单 25-24 所 


修 ° 


代码 清单 25-24 场景 类 


public class Client { 
public static void main(String[] args) { 


// 展 示 报 表 访 问 者 

IShowVisitor showVisitor = new ShowVisitor(); 

// 汇 总 报表 的 访问 者 

ITotalVisitor totalVisitor = new TotalVisitor(); 

for(Employee emp:mockEmployee())t{ 
emp.accept(showVisitor); // 接 受 展示 报表 访问 者 
emp.accept (totalVisitor );// 接 受 汇总 表 访 问 考 


} 
// 展 示 报 表 
showVisitor.report(); 
// 汇 总 报表 
totalVisitor.totalSalary(); 
} 
} 
运行 结果 如 下 所 示 : 
姓名 : 性 薪水。 工作 :编写 Java 程 序 ， 绝 对 的 蓝领 、 
张 三 。” 别 : 男 1800 兰 工 加 搬运 工 
姓名 : 性 薪水 : 工作 : 页 面 美 工 ， 审 美 素质 太 不 流行 
李 四 别 : 女 1900 0 
姓名 : 性 薪水 : 业绩 : 基本 上 是 负 值 ， 但 是 我 会 担 马 
王 五 ” 别 : 男 18750 屁 本 
本 公司 的 月 工资 总 额 是 101150 


大 家 可 以 再 深入 地 想象 ， 一 堆 数据 从 几 个 角度 来 分 析 ， 那 是 什 
么 ? 即 数 据 控 气 (Data Mining) ， 数 据 的 上 切 、 下 钻 等 处 理 ， 大 家 有 
兴趣 看 可 以 翻 看 数据 挖掘 或 者 商业 智能 (BI) 的 书 。 


25.4.3 双 分 


站 派 


说 到 访问 者 模式 就 不 得 不 提 一 下 双 分 派 (double dispatch) 问题 ， 
什么 是 双 分 派 呢 ? 我 们 先 来 解释 一 下 什么 是 单 分 派 (single dispatch) 
和 多 分 派 multiple dispatch) ， 单 分 派 语言 处 理 一 个 操作 是 根据 请 求 
者 的 名 称 和 接收 到 的 参数 决定 的 ， 在 Java 中 有 毅 态 绑 定 和 动态 绑 定 之 
说 ， 它 的 实现 是 依据 重 载 (overload) 和 履 写 (override) 实现 的 ， 我 们 
来 说 一 个 简单 的 例子 。 


例如 ， 演 员 演 电影 角色 ， 一 个 演员 可 以 扮演 多 个 角色 ， 我 们 先 定 
义 一 个 影视 中 的 两 个 角色 : 功夫 主角 和 白痢 配角 ， 如 代码 清单 25-25 所 
示 o 

代码 清单 25-25 角色 接口 及 实现 类 


public interface Role { 


// 演 员 要 扮演 的 角色 


public class KungFuRole implements Role { 


// 武 功 天 下 第 一 的 角色 


} 

public class IdiotRole implements Role { 
// 一 个 弱智 角色 

} 


角色 有 了 ， 我 们 再 定义 一 个 演员 抽象 类 ， 如 代码 清单 25-26 所 示 。 


代码 清单 25-26 抽象 演员 


public abstract class AbsActor { 
// 演 员 都 能 够 演 一 个 角色 
public void act(Role role)t{ 
System.out.println(" 演 员 可 以 扮演 任何 角色 ")， 


// 可 以 演 功 夫 戏 
public void act(KungFuRole role)t{ 

System.out .println( "演员 都 可 以 演 功 夫 和 角色 ")，; 
} 


一 


很 简单 ， 这 里 使 用 了 Java 的 重 载 ， 我 们 再 来 看 青年 演员 和 老年 演 
员 ， 采 用 和 窄 写 的 方式 来 细 化 抽象 类 的 功能 ， 如 代码 清单 25-27 所 示 。 


代码 清单 25-27 青年 演员 和 老年 演员 


public class YoungActor extends AbsActor { 
// 年 轻 演员 最 喜欢 演 功 夫 戏 
public void act(KungFuRole role)t{ 
System.out.println(" 最 喜欢 演 功 夫 和 角色")， 
} 


} 
public class OldActor extends AbsActor { 
// 不 演 功夫 角色 
public void act(KungFuRole role)t{ 
System,.out ,printlLn(" 年 龄 大 了 ， 不 能 演 功 夫 角 色 " ) ; 
} 


复写 和 重 载 都 已 经 实现 ， 我 们 编写 一 个 场景 ， 如 代码 清单 25-28 所 


修 ° 


代码 清单 25-28 场景 


public class Client { 
public static void main(String[] args) { 

// 定 义 一 个 演员 
AbsActor actor = new OldActor(); 
// 定 义 一 个 角色 
Role role = new KungFuRole( ); 
// 开 始 演戏 
actor.act(role); 
actor.act(new KungFuRole( )); 


育 看 运行 结 琳 是 什么 ? 很 商 单 ， 运 行 结 末 如 下 所 示 。 


演员 可 以 扮演 任何 角色 


年 龄 大 了 ， 不 能 演 功 夫 角 色 


重 载 在 编译 右 期 束 决 是 了 要 调用 哪个 方法 ， 它 是 根据 role 的 表面 类 
ee 静态 绑 定 ; 而 Actor 的 执行 方法 
act 则 是 由 其 实际 类 型 决定 的 ， 这 是 动态 绑 定 。 


一 个 演员 可 以 扮演 很 多 角色 ， 我 们 的 系统 要 适应 这 种 变化 ， 也 整 
征 根据 演员 、 角 色 两 个 对 象 类 型 ， 完 成 不 同 的 操作 任务 ， 该 如 何 实现 
呢 ? 很 位 单 ， 我 们 让 访问 者 模式 上 场 束 可 以 解决 该 问题 ， 只 要 把 角色 
类 稍稍 修改 即 可 ， 如 代码 清单 25-29 所 示 。 


代码 清单 25-29 引入 访问 者 模式 


public interface Role { 


// 演 员 要 扮演 的 角色 


Dubin void accept(AbsActor actor); 


public class KungFuRole implements Role { 
// 武 功 天 下 第 一 的 角色 
public void accept(AbsActor actor)t{ 
actor .act(this); 
} 


} 
public class IdiotRole implements Role { 
// 一 个 弱智 角色 ， 由 谁 来 扮 兴 
public void accept(AbsActor actor)t{ 
actor .act(this); 
} 


汪 


场景 类 稍 有 改动 ， 如 代码 清单 25-30 所 示 。 


代码 清单 25-30 场景 类 


public class Client { 
public static void main(String[] args) { 


// 定 义 一 个 演员 


AbsActor actor = new OldActor(); 
// 定 义 一 个 角色 

Role role = new KungFuRole( ); 
// 开 始 演戏 


role.accept(actor); 


一 


运行 结果 如 下 所 示 。 


年 龄 大 了 ， 不 能 演 功 夫 角 色 


看 到 没 ? 不 管 演员 类 和 角色 类 怎么 变化 ， 我 们 都 能 够 找到 期 望 的 
方法 和 运行， 这 就 是 双 反 派 。 双 分 派 意 味 着 得 到 执行 的 操作 决定 于 请 求 
的 种 类 和 两 个 接收 着 的 类 型 ， 它 是 多 分 派 的 一 个 特例 。 从 这 里 也 可 以 
看 到 Java 是 一 个 文 持 双 分 派 的 单 分 派 语 言 。 


25.5 最 佳 实践 


访问 者 模式 征 一 种 集中 规整 模式 ， 特 别 适 用 于 大 规模 重 构 的 项 
目 ， 在 这 一 个 阶段 需求 已 经 非常 清晰 ， 原 系统 的 功能 点 也 已 经 明确 ， 
通过 访问 者 模式 可 以 很 容易 把 一 些 功 能 进行 梳理 ， 达 到 最 终 目 的 一 一 
功能 集中 化 ， 如 一 个 统一 的 报表 运算 、UI 展 现 等 ， 我 们 还 可 以 与 其 他 
模式 混纺 建立 一 套 目 己 的 过 滤 闫 或 者 拦截 器 ， 请 大 家 参考 混 编 模式 的 
相关 章节 。 


第 26 章 ”状态 模式 


26.1 城市 的 纵 回 发 展 功臣 一 电梯 


现在 城市 发 展 很 快 ， 百 万 级 人 口 的 城市 很 多 ， 那 其 中 有 两 个 东西 
的 发 明 在 城市 的 发 展 中 起 到 非 党 重要 的 作用 :一 个 是 汽车 ， 男 一 个 是 
电 标 。 汽 车 让 城市 可 以 模 同 扩展 ， 电 梯 让 城市 可 以 纵 辣 延 华 ， 癌 空中 
伸展 。 汽 车 对 城市 的 发 展 我 们 束 不 说 了 ， 电 标 ， 你 想 想 看 ， 如 果 没 有 
电梯 ， 每 天 你 需要 扑 15 层 楼 梯 ， 你 是 不 是 会 过 坏 了 ? 建筑 师 设计 了 一 
个 没有 电梯 的 建筑 ， 投 资 者 肯定 不 愿意 投资 ， 那 也 是 建筑 师 的 耻辱， 
今天 我 们 就 用 程序 表现 一 下 这 个 电梯 是 怎么 运作 的 。 


我 们 每 天 都 在 乘 电梯 ， 那 我 们 来 看 看 电梯 有 哪些 动作 (映射 到 Java 
中 殊 是 有 多 少 方法 ，: 开门、 关门、 运行、 停止。 好 ， 我 们 就 用 程序 
来 实现 一 下 电 柳 的 动作 ， 先 看 类 图 设计 ， 如 图 26-1 所 示 。 


<<interface>> 
ILift 


| 
rn 
+void close() 
+void run() 


+void top() 


Lift 
上 === 寺 
图 26-1 电梯 的 类 图 


非常 简单 的 类 图 ， 定 义 一 个 接口 ， 然 后 是 一 个 实现 类 ， 然 后 业务 
场景 类 Client 束 可 以 调用 ， 并 运行 起 来 ， 人 商 单 也 要 实现 出 来 。 看 看 该 程 
序 的 接口 ， 如 代码 清单 26-1 所 示 。 


代码 清单 26-1 电梯 接口 


public interface ILift { 
// 首 先 电梯 门 开启 动作 
public void open(); 
// 电 梯 门 可 以 开局 ， 那 当然 也 就 有 关闭 了 
public void close(); 
// 电 梯 要 能 上 能 下 
public void run(); 
// 电 梯 还 要 能 停 下 来 
public void stop(); 


接口 有 了 ， 表 来 看 实现 类 ， 如 代码 清单 26-2 所 示 。 


代码 清单 26-2 电梯 实现 类 


public class Lift implements ILift { 


的 


// 电 梯 门 关闭 

public void close() { 
System.out.println(" 电 梯 门 关闭 ,.."); 

} 


// 电 梯 门 开启 
public void open() { 

System.out.println(" 电 梯 门 开 
} 


// 电 梯 开 始 运行 起 来 
public void run() { 
System.out.println(" 电 梯 上 下 运行 起 来 ...")，; 


} 

// 电 梯 停 止 

public void stop() { 
System.out.println(" 电 梯 停 止 了 ..."); 


电梯 的 开 、 关 、 运 行 、 停 都 实现 了 ， 再 看 看 场景 类 是 怎么 调用 
如 代码 清单 26-3 所 示 。 


代码 清单 26-3 场景 类 


public class Client { 


public static void main(String[] args) { 
ILift lift = new Lift(); 
// 首 先是 电梯 门 开启 ， 人 进去 
1ift.open( ); 
// 然 后 电梯 门 关闭 
1ift.close( ); 
// 再 然后 ， 电 梯 运 行 起 来 ， 向 上 或 者 向 下 
1ift.run(); 
// 最 后 到 达 目 的 地 ， 电 梯 停 下 来 
1ift.stop(); 
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运行 的 结果 如 下 所 示 : 


EE 梯 门 开启 .… 


E 梯 门 关 闭 ..… 


EE 梯 上 下 运行 起 来 .… 


E 梯 停止 了 .… 


太 简 单 的 程序 了 ! 每 个 程序 员 都 会 写 这 个 程序 ， 这 么 简单 的 程序 
还 拿 出 来 显摆 ， 有 是 不 是 太 小 看 我 们 的 智商 了 ? 非 也 ， 非 也 ， 我 们 继续 
往 下 分 析 ， 这 个 程序 有 什么 问题 ? 你 想 想 ， 电 梯 门 可 以 打开 ， 但 不 是 
随时 都 可 以 开 ， 是 有 前 提 条 件 的 。 你 不 可 能 电梯 在 运行 的 时 候 突然 开 
门 吧 ? ! 电梯 也 不 会 出 现 停止 了 但 是 不 开门 的 情况 吧 ? ! 那 要 是 有 也 
是 事故 嘛 ， 再 仔细 想 想 ， 电 梯 的 这 4 个 动作 的 执行 都 有 前 置 条 件 ， 具 体 
扩 说 束 是 在 特定 状态 下 才能 做 特定 事 ， 那 我 们 来 分 析 一 下 电梯 有 了 哪些 


特定 状态 。 


e 敞 门 状态 


按 了 电梯 上 下 按钮 ， 电 梯 门 开 ， 这 中 间 大 概 有 10 秒 的 时 间 ， 那 就 
征 敞 门 状 态 。 在 这 个 状态 下 电梯 只 能 做 的 动作 是 关门 动作 。 


e 加 | 状态 


电梯 门 关 团 了 ， 在 这 个 状态 下 ， 可 以 进行 的 动作 是 : 开门 (我 不 
想 坐 电梯 了 ) 、 停 止 (起 记 按 路 层 号 了 ) 、 运 行 。 


e 运行 状态 


电梯 正在 跑 ， 上 下 窜 ， 在 这 个 状态 下 ， 电 梯 只 能 做 的 是 停止 。 
e 停止 状态 


电梯 停止 不 动 ， 在 这 个 状态 下 ， 电 梯 有 两 个 可 选 动作 : 继续 运行 
和 开门 动作 。 


我 们 用 一 张 表 来 表示 电梯 状态 和 动作 之 间 的 关系 ， 如 图 26-2 所 示 。 


(open) 关门 (close) 停止 (stop) 


敞 门 状态 六 
O 
O 
O 


闭 门 状态 


T 
运行 状态 


停止 状态 


关 | 他 | 订 | 店 | 总 


图 26-2 电梯 状态 和 动作 对 应 表 〈o 表 示 不 允许 ， 交 表示 允许 动作 ) 


看 到 这 张 表 后 ， 我 们 才 发 觉 ， 哦 ， 我 们 的 程序 做 得 很 不 严谨 ， 
好 ， 我 们 来 修改 一 下 ， 如 图 26-3 所 示 。 


在 接口 中 定义 了 4 个 第 量 ， 分 别 表示 电梯 的 4 个 状态 ， 敞 门 状态 、 
闭 门 状态 、 运 行 状态 、 停 止 状态 ， 然 后 在 实现 类 中 电 标 的 每 一 次 动作 
发 生 都 要 对 状态 进行 判断 ， 判 断 是 否 可 以 执行 ， 也 就 是 动作 的 执行 是 
人 否 符 合 业 务 人 逻辑， 实现 类 中 有 4 个 私有 方法 是 仅仅 实现 电梯 的 动作 ， 没 


有 任何 前 置 条 件 ， 因 此 这 4 个 方法 是 不 能 为 外 部 类 调用 的 ， 设 置 为 私有 
方法 。 我 们 先 看 接口 的 改变 ， 如 代码 清单 26-4 所 示 。 


Client 
tfinal static mt OPENING STATE = ] 
+final static mt CLOSING STATE = 2 
+final static mtRUNNING STATE = 3 
+final static int STOPPING STATE =4 


+Vold open() 
tvoid close() 
+void run() 
+Vold stop() 


4 个 私有 方法 代表 的 是 没 -Vold close WithoutLogic() 


,四 # 粳 | Re 二 作料 | 4 -Vold openWithoutLogic() 


-Vold stopWithoutLogic() 


图 26-3 增加 了 状态 的 类 图 


代码 清单 26-4 电梯 接口 


public interface ILift { 
// 电 梯 的 4 个 状态 
public final static int OPENING STATE = 1; // 敞 门 状态 


public final static int CLOSING_STATE = 2; // 闭 门 状态 
public final static int RUNNING_STATE = 3; // 运 行 状态 
public final static int STOPPING_STATE = 4; // 停 止 状态 
// 设 置 电梯 的 状态 

public void setState(int state); 

// 首 先 电 梯 门 开启 动作 

public void open(); 

// 电 梯 门 可 以 开启 ， 那 当然 也 就 有 关闭 了 

public void close(); 

// 电 梯 要 能 上 能 下 ， 运 行 起 来 

public void run(); 

// 电 梯 还 要 能 停 下 来 

public void stop(); 


这 里 增加 了 4 个 静态 音量 ， 并 增加 了 一 个 方法 setState， 设 置 电梯 的 
状态 。 我 们 再 来 看 实现 类 是 如 何 实现 的 ， 如 代码 清单 26-5 所 示 。 


代码 清单 26-5 电梯 实现 类 


public class Lift implements ILift { 
private int state; 
public void setState(int state) { 
this.state = state; 
} 


// 电 梯 门 关闭 
public void close() { 
// 电 梯 在 什么 状态 下 才能 关闭 
switch(this.state)t{ 
case OPENING_STATE:; // 可 以 关门 ， 同 时 修改 电梯 状 


态 
this.closeWithoutLogic( ); 
this.setState(CLOSING STATE); 
break; 
case CLOSING_STATE: // 电 梯 是 关门 状态 ， 则 什么 都 
不 做 


//do nothing,; 
break; 
case RUNNING_STATE: // 正 在 运行 ， 门 本 来 就 是 关闭 


的 ， 也 什么 都 不 做 
//do nothing; 
break; 
case STOPPING_STATE: // 停 止 状态 ， 门 也 是 关闭 


的 ， 什 么 也 不 做 


} 


/LA 


梯 门 开启 


public void open() 


E 梯 在 什么 状态 才能 


么 都 不 做 


人 


/Ai 


//do nothing; 
break; 


HL 


switch(this.state)t{ 


} 


} 
// 电 梯 开 始 运行 起 来 


public void run() { 


case OPENING STATE: // 闭 门 状态 ,什么 都 不 做 


//do nothing; 

break; 

CLOSING_STATE: // 闭 门 状态 ， 则 可 以 开启 
this.openwithoutLogic( ); 
this.setState(OPENING STATE); 
break; 

RUNNING_STATE:; // 运 行 状态 ， 则 不 能 开门 ， 什 


//do nothing; 
break; 


case STOPPING_STATE: // 停 止 状态 ， 当 然 要 开门 了 


this.openwithoutLogic( ); 
this.setState(OPENING_ STATE); 
break; 


switch(this.state)t{ 


/AI 


电梯 停止 


public void stop() { 
switch(this.state)t{ 


case OPENING_STATE: // 敞 门 状 态 ， 什 么 都 不 做 


//do nothing; 

break; 

CLOSING_STATE: // 闭 门 状态 ， 则 可 以 运行 
this.runwithoutLogic( ) ; 
this,setState(RUNNING_STATE ) ， 

break ; 

RUNNING_STATE: // 运 行 状态 ， 则 什么 都 不 做 
//do nothing; 

break; 


case STOPPING_STATE: // 停 止 状态 ， 可 以 运行 


this.runwithoutLogic( ) ; 
this,setState(RUNNING_STATE ) ， 


case OPENING_STATE: // 敞 门 状态 ， 要 先 停 下 来 的 ， 什 么 都 
不 做 

//do nothing; 
break; 

case CLOSING_STATE; // 闭 门 状态 ， 则 当然 可 以 停止 了 
this.stopwithoutLogic( ); 
this.setState(CLOSING STATE); 
break; 

case RUNNING_STATE: // 运 行 状态 ， 有 运行 当然 那 也 就 有 停 


止 了 
this.stopwithoutLogic( ) ; 
thlis.setState(CLOSING_STATE ) ， 
break; 
case STOPPING_STATE: // 停 止 状态 ,什么 都 不 做 

//do nothing; 
break; 

l } 

// 纯 粹 的 电梯 关门 ， 不 考虑 实际 的 逻辑 

private void closeWithoutLogic(){ 

System.out.println(" 电 梯 门 关闭 ...")， 
} 


// 纯 粹 的 电梯 开门 ， 不 考虑 任何 条 件 
private void openWithoutLogic(){ 
System.out.println(" 电 梯 门 开 


} 

// 纯 粹 的 运行 ， 不 考虑 其 他 条 件 

private void runwithoutLogic( ){ 
System.out.println(" 电 梯 上 下 运行 起 来 ...")，; 


} 

// 单 纯 的 停止 ， 不 考虑 其 他 条 件 

private void StopwithoutLogic( ){ 
System.out .println(" 电 梯 停 止 了 . ,.") ， 

} 


HL 


测 


程序 有 点 长 ， 但 是 还 是 很 简单 的 ， 束 是 在 每 一 个 接口 定义 的 方法 
中 使 用 switch...case 来 判断 它 是 否 符合 业务 逻辑 ， 然 后 运行 指定 的 动 
作 。 我 们 重新 编写 一 个 场景 类 来 描述 一 下 该 环境 ， 如 代码 清单 26-6 所 


修 ° 


代码 清单 26-6 场景 


public class Client { 
public static void main(String[] args) { 

ILift 1ift = new Lift(); 
// 电 梯 的 初始 条 件 应 该 是 停止 状态 
1ift.setState(ILift.STOPPING_ STATE); 
// 首 先是 电梯 门 开启 ， 人 进去 
1ift.open( ); 
// 然 后 电梯 门 关 闭 
1ift.close( ); 
// 再 然后 ， 电 梯 运 行 起 来 ， 向 上 或 者 向 下 
1ift.run(); 
// 最 后 到 达 目 的 地 ， 电 梯 停 下 来 
1ift.stop(); 


在 业务 调用 的 方法 中 增加 了 电梯 状态 判断 ， 电 梯 要 不 征 随 时 都 可 
以 开 的 ， 必 须 满 足 一 定 条 件 才 能 开门 ， 人 才能 走 进 去 ， 我 们 设置 电 樟 
的 起 始 是 停止 状态 ， 运 行 结果 如 下 所 示 : 


EE 梯 门 开启 .… 


EE 梯 门 关闭 ..… 


外 梯 上 下 运行 起 来 .… 


E 梯 停止 了 .… 


我 们 来 想 一 下 ， 这 段 程序 有 什么 问题 。 


e 电 樟 实 现 类 Lift 有 点 长 


长 的 原因 是 我 们 在 程序 中 使 用 了 大 量 的 switch...case 这 样 的 判断 
(if...else 也 是 一 样 ) ， 程 序 中 只 要 有 这 样 的 判断 就 避免 不 了 加 长 程 


序 ， 而 且 在 业务 复杂 的 情况 下 ， 程 序 会 更 长 ， 这 就 不 是 一 个 很 好 的 习 
惯 了 ， 较 长 的 方法 和 类 无 法 带 来 良好 的 维护 性 ， 毕 竟 ， 程 序 首 移 是 给 
人 阅读 的 ， 然 后 才 是 机 器 执行 。 


e 扩展 性 非常 差劲 


大 家 来 想 想 ， 电 梯 还 有 两 个 状态 没有 加 ， 是 什么 ? 通电 状态 和 断 
电 状 态 ， 你 要 是 在 程序 增加 这 两 个 方法 ， 你 看 看 Open()、Close()、 
Run0、StopO 这 4 个 方法 都 要 增加 判断 条 件 ， 也 就 是 说 switch 判 断 体 中 
还 要 增加 case 项 ， 这 与 开 闭 原则 相 违 背 。 


e 非常 规 状 态 无 法 实现 


我 们 来 思考 我 们 的 业务 ， 电 梯 在 | 敞开 状态 下 整 不 能 上 下 运行 了 
吗 ? 电梯 有 没有 发 生 过 只 有 运行 没有 集 止 状态 呢 (从 40 层 直接 除 到 1 层 
嘛 ) ? 电梯 故障 嘛 ， 还 有 电梯 在 检修 的 时 候 ， 可 以 在 stop 状 态 下 不 开 
门 ， 这 也 是 正常 的 业务 需求 呀 ， 你 想 想 看 ， 如 果 加 上 这 些 判断 条 件 ， 
上 面 的 程序 有 多 少 需 要 修改 ? 虽然 这 些 都 是 电梯 的 业务 逻辑 ， 但 是 一 
个 类 有 且 仅 有 一 个 原因 引起 类 的 变化 ， 单 一 职 贡 原则 ， 看 看 我 们 的 
类 ， 业 务 任务 上 一 个 小 小 的 增加 或 改动 都 使 得 我 们 这 个 电梯 类 产生 了 
修改 ， 这 在 项 目 开 发 上 十 有 很 大 风险 的 。 


既然 我 们 已 经 发 现 程序 中 有 以 上 问题 ， 我 们 怎么 来 修改 呢 ? 刚刚 
我 们 是 从 电梯 的 方法 以 及 这 些 方 法 执行 的 条 件 去 分 析 ， 现 在 我 们 换个 


角度 来 看 问题 。 我 们 来 想 ， 电 梯 在 具有 这 些 状态 的 时 候 能 够 做 什么 事 
情 ， 也 融 是 说 在 电梯 处 于 某 个 具体 状态 时 ， 我 们 来 思考 这 个 状态 十 由 
什么 动作 触发 而 产生 的 ， 以 及 在 这 个 状态 下 电梯 还 能 做 什么 事情 。 例 
如 ， 电 梯 在 停止 状态 时 ， 我 们 来 思考 两 个 问题 ; 


e 停止 状态 是 怎么 来 的 ， 那 当然 是 由 于 电梯 执行 了 stop 方 法 而 来 
的 。 


e 在 停止 状态 下 ， 电 梯 还 能 做 什么 动作 ? 继续 运行 ? 开门 ? 当然 都 
可 以 了 。 


我 们 再 来 分 析 其 他 3 个 状态 ， 也 都 是 一 样 的 结果 ， 我 们 只 要 实现 电 
梯 在 一 个 状态 下 的 两 个 任务 模型 就 可 以 了 : 这 个 状态 是 如 何 产生 的 ， 
以 及 在 这 个 状态 下 还 能 做 什么 其 他 动作 (也 就 是 这 个 状态 怎么 过 渡 到 
其 他 状态 ) ， 既 然 我 们 以 状态 为 参考 模型 ， 那 我 们 就 和 完 定义 电梯 的 状 
态 搂 口 ， 类 图 如 图 26-4 所 示 。 


每 个 状态 下 还 是 有 4 个 方 法 ， 
各 个 状态 下 的 实 更 方法 十 不 同 的 


Context LiftState 


#Context context 


+LiftState getLittState() 


tvoid setLiftState(LiftState hiftState) +void setContext(Context _context) 


+void open() +void open() 
+void close() tyoid closel) 
+vold run() +void run() 
+void stop() tyoid stop() 


承担 的 是 环境 角色 ， 也 就 是 封装 类 


OpenningState ClosingState RunningState Stopping 


图 26-4 以 状态 作为 导向 的 类 图 


在 类 图 中 ， 定 义 了 一 个 LiftState 抽 象 类 ， 声 明了 一 个 受 保护 的 类 型 
Context 变 量 ， 这 个 是 串联 各 个 状态 的 封 狠 类。 封 泌 的 目的 很 明显 ， 玖 
征 电梯 对 象 内 部 状态 的 变化 不 被 调用 类 知晓 ， 也 就 是 迪 米 特 法 则 了 

(我 的 类 内 部 情节 你 知道 得 越 少 越 好 ) ， 并 且 还 定义 了 4 个 具体 的 实现 
类 ， 承 担 的 是 状态 的 产生 以 及 状态 间 的 转换 过 渡 ， 我 们 先 来 看 LiftState 
代码 ， 如 代码 清单 26-7 所 示 。 


代码 清单 26-7 抽象 电梯 状态 


public abstract class LiftStatet 
// 定 义 一 个 环境 角色 ， 也 就 是 封装 状态 的 变化 引起 的 功能 变化 
protected Context context; 
public void setContext(Context _context){ 
this.context = _context; 


// 首 先 电梯 门 开 启动 作 


public abstract void open( ) ， 
// 电 梯 门 有 开启 ， 那 当然 也 就 有 关闭 了 
public abstract void close(); 
// 电 梯 要 能 上 能 下 ， 运 行 起 来 
public abstract void run(); 
// 电 梯 还 要 能 停 下 来 

public abstract void stop(); 


IJ 


抽象 类 比较 简单 ， 我 们 先 看 一 个 具体 的 实现 一 一 敞 门 状态 的 实现 
类 ， 如 代码 清单 26-8 所 示 。 


代码 清单 26-8 敞 门 状态 


public class OpenningState extends LiftState { 

// 开 启 当 然 可 以 关闭 了 ， 我 就 想 测 试 一 下 电梯 门 开 关 功 能 

Q@Override 

public void close() { 
// 状 态 修改 
super .context .setLiftState(Context .closeingState ) ; 
// 动 作 委托 为 CLoseState 来 执行 
Super .context .getLiftState().close(); 


} 

// 打 开 电 梯 门 

@Override 

public void open() { 
System.out.println(" 电 梯 门 开启 ..,")， 


} 
// 门 开 着 时 电梯 就 运行 跑 ， 这 电梯 ， 吓 死 你 ! 
@Override 
public void run() { 
//do nothing; 


} 

/V 开 门 还 不 停止 ? 

public void stop() { 
//do nothing; 

， 


我 来 解释 一 下 这 个 类 的 几 个 方法 ，Openning 状 态 是 由 open0 方 法 产 
生 的 ， 因 此 ， 在 这 个 方法 中 有 一 个 具体 的 业务 逻辑 ， 我 们 是 用 print 来 


代 替 了 。 在 Openning 状 在下 ， 电 梯 能 过 波 到 其 他 什么 状态 呢 ? 按照 现 
在 的 定义 的 是 只 能 过 洲 到 Closing 状 态 ， 因 此 我 们 在 Close0 中 定义 了 状 
态 变 更 ， 同 时 把 Close 这 个 动作 也 委托 了 给 CloseState 类 下 的 Close 方 法 执 

文 个 可 能 不 好 理解 ， 我 们 再 看 看 Context 类 可 能 好 理解 一 点 ， 如 代 
码 清 单 26-9 所 示 。 


代码 清单 26-9 上 下 文 类 


public class Context { 

// 定 义 出 所 有 的 电梯 状态 

public final static OpenningState openningState = new 
OpenningState( ); 

public final static ClosingState closeingState = new 
Closingstate( ) ; 

public final static RunningState runningState = new 
RunningState( ); 

public final static StoppingState stoppingState = new 
StoppingState( ); 

// 定 义 一 个 当前 电梯 状态 

private LiftState liftState; 

public LiftState getLiftState() { 

return liftState; 


public void setLiftState(LiftState liftState) { 
this.1liftState = liftState; 
// 把 当前 的 环境 通知 到 各 个 实现 类 中 
this.1iftState.setContext(this); 


} 
public void open(){ 
this,.1iftState.open(); 


public void close(){ 
this.1liftState.close(); 


public void run(){ 
this,.1iftState.run( ); 


public void stop(){ 
this.1iftState.stop(); 


结合 以 上 3 个 类 ， 我 们 可 以 这 样 理解 : Context 是 一 个 环境 角色 ， 
的 作用 是 串联 各 个 状态 的 过 渡 ， 在 LiftSate 抽 象 类 中 我 们 定义 并 把 这 
环境 角色 聚合 进来 ， 并 传递 到 于 类 ， 也 融 是 4 个 具体 的 实现 类 中 目 己 根 
据 环 境 来 决定 如 何 进行 状态 的 过 渡 。 关 闭 状态 如 代码 清单 26-10 所 示 。 


代码 清单 26-10 关闭 状态 


public class ClosingState extends LiftState { 
// 电 梯 门 关闭 ， 这 是 关闭 状态 要 实现 的 动作 
Q@Override 
public void close() { 
System.out.println(" 电 梯 门 关闭 ,..")，; 
} 


// 电 梯 门 关 了 再 打开 
@Override 
public void open() { 
super .context.setLiftState(Context.openningState); 
// 置 为 敞 门 状态 
Super .context .getLiftState(),open( ); 
} 


// 电 梯 门 关 了 就 运行 ， 这 是 再 正常 不 过 
Q@Override 
public void run() { 
super .context .SetLiftState(Context .runningState ) ; 
// 设 置 为 运行 状态 
Super .context.getLiftState().run(); 
} 


// 电 梯 门 关 着 ， 我 束 不 按 楼 层 
@Override 
public void stop() { 
super .context .SetLiftState(Context .StoppingState ) ; 
// 设 置 为 停止 状态 
super .context.getLiftState().stop(); 
} 


运行 状态 如 代码 清单 26-11 所 示 。 


代码 清单 26-11 运行 状态 


public class RunningState extends LiftState { 
// 电 梯 门 关闭 ? 这 是 肯定 的 
@Override 
public void close() { 
//do nothing 


} 
// 运 行 的 时 候 开 电 梯 门 ?你 疯 了 ! 电梯 不 会 给 你 开 的 
@Override 
public void open() { 
//do nothing 


} 

// 这 是 在 运行 状态 下 要 实现 的 方法 

@Override 

public void run() { 
System.out.println(" 电 梯 上 下 运行 ...")， 


} 
// 这 绝对 是 合理 的 ， 只 运行 不 停止 还 有 谁 敢 坐 这 个 电梯 ? ! 估计 只 有 上 帝 了 
Q@Override 


public void stop() { 


super.context.setLiftState(Context .stoppingState);// 环 境 设置 为 停止 
状态 


super.context.getLiftState().stop(); 


停止 状态 如 代码 清单 26-12 所 示 。 


代码 清单 26-12 停止 状态 


public class StoppingState extends LiftState { 
// 停 止 状 态 关 门 ? 电梯 门 本 来 束 是 关 着 的 ! 
@Override 
public void close() { 
//do nothing; 


} 
// 停 止 状态 ， 开 门 ， 那 是 要 的 ! 
Q@override 
public void open() { 
Super .context .setLiftState(Context .openningState ) ; 
Super .context .getLiftState(),open( ); 


} 

// 停 止 状 态 再 运行 起 来 ， 正 常 得 很 

@Override 

public void run() { 
super .context .setLiftState(Context .runningState ) ; 
Super .context .getLiftState(),run(); 


} 

// 停 止 状态 是 怎么 发 生 的 呢 ? 当然 是 停止 方法 执行 了 

Q@Override 

public void stop() { 
System.out.println(" 电 梯 停 止 了 .,.")， 


业务 逻辑 都 已 经 实现 了 ， 我 们 看 看 怎么 来 模拟 场景 类 ， 如 代码 清 
单 26-13 所 示 。 


代码 清单 26-13 场景 


public class Client { 

public static void main(String[] args) { 
Context context = new Context(); 
context.setLiftState(new ClosingState() ) ， 
context ,open( ) ; 
context.close(); 
context .run( ); 
context ,Stop() ; 


Client 场 景 尖 太 简 单 了 ， 只 要 定义 一 个 电梯 的 初始 状态 ， 然 后 调用 
相关 的 方法 ， 束 完成 了 ， 完 全 不 用 考虑 状态 的 变更 ， 运 行 结 琳 完 全 相 
同 ， 不 再 性 述 。 


我 们 再 来 回顾 一 下 我 们 刚刚 批判 的 上 一 段 代码 。 育 先生 代码 太 
长 ， 这 个 问题 已 经 解决 了 ， 通 过 各 个 子 类 来 实现 ， 每 个 子 类 的 代码 都 


很 短 ， 而 且 也 取消 了 switch...case 条 件 的 判断 。 其 次 是 不 符合 开 闭 原 
则 ， 那 如 时 在 我 们 这 个 例子 中 要 增加 两 个 状态 应 该 怎么 做 呢 ? 增加 两 
个 子 类 ， 一 个 是 通电 状态 ,为 一 个 是 断 电 状 态 ， 同 时 修改 其 他 实现 类 
的 相应 方法 ， 因 为 状态 要 过 滤 ， 那 当然 要 修改 原 有 的 类 ， 只 是 在 原 有 
类 中 的 方法 上 增加 ， 而 不 去 做 修改 。 再 次 是 不 符合 迪 米 特 法 则 ， 我 们 
现在 的 各 个 状态 是 单独 的 类 ， 只 有 与 这 个 状态 有 关 的 因素 修改 了 ， 这 
个 类 才 修 改 ， 符 合 迪 米 特 法 则 ， 非 常 完美 ! 这 就 是 状态 模式 。 


26.2 状态 模式 的 定义 


上 面 的 例子 中 多 次 提 到 状态 ， 本 市 讲 的 束 古 状态 模式 ， 什 么 是 状 
态 模式 呢 ? 其 定义 如 下 : 


Allow an object to alter its behavior when its internal state 


changes.The object will appear to change its class. 〈 当 一 个 对 象 内 在 状态 
改变 时 允许 其 改变 行为 ， 这 个 对 象 看 起 来 像 改变 了 其 类 。) 


状态 模式 的 核心 是 封装 ， 状 态 的 变更 引起 了 行为 的 变更 ， 从 外 部 
看 起 来 就 好 像 这 个 对 象 对 应 的 类 发 生 了 改变 一 样 。 状 态 模式 的 通用 类 
图 如 图 26-5 所 示 。 


十 State 


Context 
| 


+Request() 


图 26-5 状态 模式 通用 类 图 


我 们 先 来 看 看 状态 模式 中 的 3 个 角色 。 


@ State 


抽象 状态 角色 


接口 或 抽象 类 ， 负 责 对 象 状 态 定 义 ， 并 且 封 装 环 境 角色 以 实现 状 
态 切换 。 


@ ConcreteState 


具体 状态 角色 


每 一 个 具体 状态 必须 完成 两 个 职责 : 本 状态 的 行为 管理 以 及 趋同 
状态 处 理 ， 通 俗 地 说 ， 束 古本 状态 下 要 做 的 事情 ， 以 及 本 状态 如 何 过 


渡 到 其 他 状态 。 


环境 角色 


@ Context 


定义 客户 端 需要 的 接口 ， 并 且 人 负责 具体 状态 的 切换 。 


状态 模式 相对 来 说 比较 复杂 ， 它 提供 了 一 种 对 物质 运动 的 玖 一 个 
观察 视角 ， 通 过 状态 变更 促使 行为 的 变化 ， 融 类 似 水 的 状态 变更 一 
样 ， 一 碗 水 的 初始 状态 是 液态 ， 通 过 加 热 转 变 为 气态， 状态 的 改变 同 
时 也 引起 体积 的 扩大 ， 然 后 就 产生 了 一 个 新 的 行为 : 吗 什 或 项 起 壹 
盖 ， 瓦 特 就 古 这 么 发 明 茹 汽机 的 。 我 们 再 来 看 看 状态 模式 的 通用 源 代 

码 ， 首 先 来 看 抽象 环境 角色 ， 如 代码 清单 26-14 所 示 。 


代码 清单 26-14 抽象 环境 角色 


public abstract class State { 
// 定 义 一 个 环境 角色 ， 提 供 子 类 访问 
protected Context context; 
// 设 置 环境 角色 
public void setContext(Context _context){ 
this.context = _context,; 


Dd 

public abstract void handlel1( ); 

// 行 为 2 

public abstract void handle2(); 

抽象 环境 中 声明 一 个 环境 角色 ， 提 供 各 个 状态 类 目 行 访问 ， 并且 
提供 所 有 状态 的 抽象 行为 ， 由 各 个 实现 类 实现 。 具 体 环境 角色 如 代码 


清单 26-15 所 示 。 


代码 清单 26-15 环境 角色 


public class ConcreteState1 extends State { 
@Override 
public void handle1() { 
// 本 状态 下 必须 处 理 的 逻辑 


@Override 

public void handle2() { 
// 设 置 当前 状态 为 stat2 
Super .context ,SetCurrentState(Context .STATE2 ) ; 
// 过 渡 到 state2 状 态 ， 由 Context 实 现 
super.context.handle2( ); 


3 


public class ConcreteState2 extends State { 
@Override 
public void handle1() { 
// 设 置 当前 状态 为 statel 
Super .context ,SetCurrentState(Context .STATE1T) ; 
// 过 渡 到 state1 状 态 ， 由 Context 实 现 
super.context.handle1( ); 


@Override 
public void handle2() { 

// 本 状态 下 必须 处 理 的 逻辑 
} 


具体 环境 角色 有 两 个 职责 : 处 理 本 状态 必须 完成 的 任务 ， 决 定 是 
否 可 以 过 波 到 其 他 状态 。 我们 再 来 看 环境 角色 ， 如 代码 清单 26-16 所 


[© 
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代码 清单 26-16 具体 环境 角色 


public class Context { 
// 定 义 状 态 
public final static State STATE1 
public final static State STATE2 
// 当 前 状态 
private State CurrentState; 


new ConcreteState1( ) ， 
new ConcreteState2(); 


// 获 得 当前 状态 
public State getCurrentState() { 
return CurrentState; 


} 

// 设 置 当 前 状态 

public void setCurrentState(State currentState) { 
this.CurrentState = currentState; 


// 切 换 状态 
this.CurrentState.setcCcontext (this); 
} 
// 行 为 委托 


public void handle1(){ 
this.CurrentState.handle1( ); 


} 
public void handle2(){ 
this.CurrentState.handle2( ); 


} 
} 

环境 角色 有 两 个 不 成 文 的 约束 ， 

。 把 状态 对 象 声 明 为 静态 常量 ， 有 几 个 状态 对 象 就 声明 几 个 静态 
常量 。 


e 环境 角色 具有 状态 抽象 角色 定义 的 所 有 行为 ， 具 体 执行 使 用 委 
jE 


我 们 再 来 看 场景 类 如 何 执 行 ， 如 代码 清单 26-17 所 示 。 


代码 清单 26-17 具体 环境 角色 


public class Client { 
public static void main(String[|] args) { 
// 定 义 环境 角色 
Context context = new Context( ) ; 
// 初 始 化 状态 
context.setCurrentState(new ConcreteStatel1( ) ) ; 
// 行 为 执行 


context ,handJlel1() ， 
context.handle2( ); 


看 到 没 ? 我 们 已 经 隐藏 了 状态 的 变化 过 程 ， 它 的 切换 引起 了 行为 
的 变化 。 对 外 来 说 ， 我 们 只 看 到 行为 的 发 生 改 变 ， 而 不 用 知道 是 状态 
变化 引起 的 。 


26.3 状态 模式 的 应 用 
26.3.1 状态 模式 的 优点 


e 结构 清晰 


避免 了 过 多 的 switch...case 或 者 if...else 语 句 的 使 用 ， 避 人 免 了 程序 的 
复杂 性 ,提高 系统 的 可 维护 性 。 


e 遵循 设计 原则 


很 好 地 体现 了 开 闭 原则 和 单一 职 贡 原则 ， 每 个 状态 部 是 一 个 子 
类 ， 你 要 增加 状态 束 要 增加 子 类 ， 你 要 修改 状态 ， 你 只 修改 一 个 子 类 
束 可 以 了 。 


e 封 猴 性 非常 好 


这 也 是 状态 模式 的 基本 要 求 ， 状 态 变 换 放置 到 类 的 内 部 来 实现 ， 
外 部 的 调用 不 用 知道 类 内 部 如 何 实现 状态 和 行为 的 变换 。 


26.3.2 状态 模式 的 缺点 


状态 模式 既然 有 优点 ， 那 当然 有 缺点 了 。 但 只 有 一 个 缺点 ， 子 类 
会 太 多 ， 也 束 生 类 膨胀 。 如 采 一 个 事物 有 很 多 个 状态 也 不 稀奇 ， 如 采 
全 使 用 状态 模式 融会 有 太 多 的 子 类 ， 不 好 管理 ， 这 个 需要 大 家 在 项 
中 目 己 衡量 。 其 实 有 很 多 方式 可 以 解决 这 个 状态 问题 ， 如 在 数据 库 
中 建立 一 个 状态 表 ， 然 后 根据 状态 执行 相应 的 操作 ， 这 个 也 不 复杂 ， 
看 大 家 的 习惯 和 嗜好 了 。 


三 洒落 


26.3.3 状态 模式 的 使 用 场景 


e 行为 随 状态 改变 而 改变 的 场景 


这 也 是 状态 模式 的 根本 出 发 点 ， 例 如 权限 设计 ， 人 员 的 状态 不 同 
即使 执行 相同 的 行为 结果 也 会 不 同 ， 在 这 种 情况 下 需要 考虑 使 用 状态 
模式 。 


e 条 件 、 分 支 判 断 语句 的 替代 者 


在 程序 中 大 量 使 用 switch 语 句 或 者 i 判断 语句 会 导致 程序 结构 不 清 
上 晰 ， 逻 辑 宰 瑟 ， 使 用 状态 模式 可 以 很 好 地 避免 这 一 问题 ， 它 通过 扩展 
子 类 实现 了 条 件 的 判断 处 理 。 


26.3.4 状态 模式 的 注意 事项 


状态 模式 适用 于 当 某 个 对 象 在 它 的 状态 发 生 改 变 时 ， 它 的 行为 也 
随 着 发 生 比 较 大 的 变化 ， 也 就 古 说 在 行为 受 状 态 约束 的 情况 下 可 以 使 
用 状态 模式 ， 而 且 使 用 时 对 象 的 状态 最 好 不 要 超过 5 个 。 


26.4 最 佳 实践 


上 上面 的 例子 可 能 比较 复杂 ， 请 各 位 看 官 耐心 看 ， 看 完 肯 定 有 所 收 
获 。 我 翻 遍 了 所 有 能 找 得 到 的 资料 〈 关 于 这 个 电梯 的 例子 也 是 由 
《Design Pattern for Dummies》 这 本 书 激发 出 来 的 ) ， 基 本 上 没有 一 本 
把 这 个 状态 模式 讲 透 彻 的 (当然 ， 还 是 有 几 本 讲 得 不 错 ) ， 我 不 敢 说 
我 工 讲 得 透彻 ， 大 家 都 只 讲 了 一 个 状态 到 男 一 个 状态 的 过 渡 。 状 态 间 
的 过 小 是 固定 的 ， 举 个 简单 的 例子 ， 如 图 26-6 所 示 。 


图 26-6 简单 状态 切换 示意 图 


这 个 状态 图 十 很 多 书 上 都 有 的 ， 状 态 A 只 能 切换 到 状态 B， 状 态 B 
再 切换 到 状态 C。 举 例 最 多 的 就 是 TCP 监 听 的 例子 。TCP 有 3 个 状态 : 等 
竺 状态、 连接 状态 、 断 开 状 态 ， 然 后 这 3 个 状态 按照 顺序 循环 切换 。 按 
照 这 个 状态 变更 来 讲解 状态 模式 ， 我 认为 是 不 太 合适 的 ， 为 什么 呢 ? 


你 在 项 目 中 很 少 看 到 一 个 状态 只 能 过 渡 到 男 一 个 状态 情形 ， 项 目 中 明 
到 的 大 多 数 情况 部 是 一 个 状态 可 以 转换 为 几 种 状态 ， 如 图 26-7 所 示 。 


图 26-7 复杂 状态 切换 示意 图 


状态 B 既 可 以 切换 到 状态 C， 又 可 以 切换 到 状态 D， 而 状态 D 也 可 以 
切换 到 状态 A 或 状态 B， 这 在 项 目 分 析 过 程 中 有 一 个 状态 图 可 以 完整 地 
展示 这 种 蜂 蛛 网 结构 ， 例 如 ， 一 些 收 费 网 站 的 用 户 束 有 很 多 状态 ， 如 
普通 用 户 、 普 通 会 员 、VIP 会 员 、 日 金 级 用 户 等 ， 这 个 状态 的 变更 你 不 
允许 跳跃 ? ! 这 不 可 能 ， 所 以 我 在 例子 中 束 举 了 一 个 比较 复杂 的 应 
用 ， 基 本 上 可 以 实现 状态 间 目 由 切换 ， 这 才 是 最 经 常用 到 的 状态 模 


再 提 一 个 问题 ， 状 态 间 的 目 由 切换 ， 那 会 有 很 多 种 蚜 ， 你 要 挨个 
去 牢记 一 过 吗 ? 比如 上 面 那个 电梯 的 例子 ， 我 要 一 个 正常 的 电梯 运行 
逻辑 ， 规 则 是 开门 -> 关门 -> 运行 -> 停止 ， 还 要 一 个 紧急 状态 (如 火灾 ) 
下 的 运行 逻辑 ， 关 门 -> 停止 ， 紧 急 状 态 时 ， 电 梯 当 然 不 能 用 了 ; 再 要 
一 个 维修 状态 下 的 运行 逻辑 ， 这 个 状态 任何 情况 都 可 以 ， 开 着 门 电梯 


运行 ? 可 以 ! 门 来 回 开 关 ? 可 以 ! 永久 停止 不 动 ? 可 以 ! 那 这 怎么 实 
现 呢 ? 需要 我 们 把 已 经 有 的 几 种 状态 按照 一 定 的 顺序 再 重新 组 装 一 
下 ， 那 这 个 是 什么 模式 ? 什么 模式 ? 大 声 点 ! 建造 者 模式 ! 对 ， 建 造 
模式 + 状态 模式 会 起 到 非常 好 的 封 痛 作用。 


更 进一步 ， 应 该 有 部 分 读者 做 过 工作 流 开发 ， 如 果 不 是 土 制 框 
架 ， 那 么 就 应 该 有 个 状态 机 管理 〈 即 使 是 土 制 框架 也 应 该 有 ) ， 如 一 
个 Activity (节点 ) 有 初始 化 状态 (Initialized State) 、 挂 起 状态 

(Suspended State) 、 完 成 状态 (Completed State) 等 ， 流 程 实例 也 有 
这 么 多 状态 ， 那 这 些 状态 怎么 管理 呢 ? 通 过 状态 机 (State Machine) 来 
管理 ， 那 状态 机 是 个 什么 东西 呢 ? 就 是 我 们 上 面 提 到 的 Context 类 的 升 
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第 27 半 解释 器 模式 


27.1 四 则 运算 你 会 吗 


在 银行 、 证 券 类 项 目 中 ， 经 营 会 有 一 些 模 型 运算 ， 通 过 对 现 有 数 
据 的 统计 、 分 析 而 预测 不 可 知 或 未 来 可 能 发 生 的 商业 行为 。 模 型 运算 
大 部 分 是 针对 海量 数据 的 ， 例 如 建立 一 个 模型 公式 ， 分 析 一 个 城市 的 
消费 倾向 ， 进 而 影响 银行 的 营销 和 业务 扩张 方向 。 一 般 的 模型 运算 都 
有 一 个 或 多 个 运算 公式 ， 通 常 是 加 、 减 、 乘 、 除 四 则 和 运算， 偶尔 也 有 
指数 、 开 方 等 复杂 运算 。 具 体 到 一 个 金融 业务 中 ， 模 型 公式 征 非常 复 
杂 的 ， 里 然 只 有 加 、 减 、 乘 、 除 四 则 运算 ， 但 是 公式 有 可 能 有 十 多 个 
参数 ， 而 且 上 百 个 业务 品 各 有 不 同 的 取 参 路 径 ， 同 时 相关 表 的 数据 量 
都 在 百 万 级 。 呵 呵 ， 复 杂 了 吧 ， 不 复杂 那 束 不 叫 金 融 业务 ， 我 们 来 讲 
讲 运算 的 核心 一 一 模型 公式 及 其 如 何 实 现 。 


业务 需求 ， 输 入 一 个 模型 公式 (加 、 减 运算 ) ， 然 后 输入 模型 中 
的 参数 ， 运 算出 结果 。 


设计 要 求 : 


e 公式 可 以 运行 时 编辑 ， 并 且 符合 正 币 算术 书 写 方式 ， 例 如 a+b- 


e 高 扩展 性 ， 未 来 增加 指数 、 开 方 、 极 限 、 求 导 等 运算 符号 时 较 少 
改动 。 
e 效率 可 以 不 用 考虑 ， 晚 间 批量 运算 。 


需求 不 复 洒 ， 寿 仅仅 对 数字 采用 四 则 运算 ， 每 个 程序 员 都 可 以 写 
出 来 。 但 是 增加 了 增加 模型 公式 束 复 杂 了 。 先 解释 一 下 为 什么 需要 公 
式 ， 而 不 采用 直接 计算 的 方法 ， 例 如 有 如 下 3 个 公式 : 


e 业务 种 类 1 的 公式 : a+b+c-d。 
e 业务 种 类 2 的 公式 : a+b+e-d。 
e 业务 种 类 3 的 公式 : a-f。 


其 中 ,a、b、c、d、e、f 参 数 的 值 部 可 以 取得 ， 如 琳 使 用 直接 计算 
数值 的 方法 需要 为 每 个 品种 写 一 个 算法 ， 目 前 仅仅 是 3 个 业务 种 类 ， 那 


上 百 个 品种 呢 ? 吹 菜 了 吧 ! 建立 公式 ， 然 后 通过 公式 运算 才 是 王道 。 


我 们 以 实现 加 、 减 算法 〈 由 于 篇 幅 所 限 ， 乘 、 除 法 的 运算 读者 可 
以 自行 扩展 ) 的 公式 为 例 ， 讲 解 如 何 解析 一 个 固定 语法 逻辑 。 由 于 使 
用 语法 解析 的 场景 比较 少 ， 而 且 一 些 商业 公司 (如 SAS、SPSS 等 统计 
分 析 软 件 ) 都 支持 类 似 的 规则 运算 ， 末 自 编写 语法 解析 的 工作 已 经 非 
常 少 ， 以 下 例 程 采用 逐步 分 析 方 法 ， 带 领 大 家 了 解 这 一 实现 过 程 。 


想 想 公式 中 有 什么 ? 仅 有 两 类 元 素 : 运算 元 素 和 运算 符号 ， 运 算 
元 素 忠 是 指 a、b、c 等 符号 ， 需 要 具体 赋值 的 对 象 ， 也 叫做 终结 符号 ， 
为 什么 叫 终结 符号 昵 ? 因为 这 些 元 素 除 了 需要 赋值 外 ， 不 需要 做 任何 
处 理 ， 所 有 运算 元 陛 都 对 应 一 个 具体 的 业务 参数 ， 这 是 语法 中 最 小 的 
单元 逻辑 ， 不 可 再 拆 分 ， 运 算 符号 就 是 加 减 符号 ， 需 要 我 们 编写 算法 
进行 处 理 ， 每 个 运算 符号 都 要 对 应 处 理 单元 ， 否 则 公式 无 法 运行 ， 运 
算 符号 也 叫做 非 终结 符号 。 两 尖 元 聚 的 共同 点 是 都 要 被 解 林 ， 不 同 点 
征 所 有 的 运算 元 系 具 有 相同 的 功能 ， 可 以 用 一 个 类 表示 ， 而 运算 符号 
则 是 需要 分 别 进行 解释 ， 加 法 需要 加 法 解析 器 ， 减 法 需要 减法 解析 
如 。 分 析 到 这 里 ， 我 们 束 可 以 先 画 一 个 简单 的 类 图 ， 如 图 27-1 所 示 。 
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加 法 解析 


图 27-1 初步 分 析 加 减法 类 图 


这 是 一 个 很 简单 的 类 图 ，VarExpression 用 来 解析 运算 元 素 ， 各 个 公 
式 能 运算 元 素 的 数量 是 不 同 的 ， 但 每 个 运算 元 素 都 对 应 一 个 
VarExpression 对 象 。SybmolExpression 人 负责 解析 符号 ， 由 两 个 子 类 


AddExpression (负责 加 法 运算 ) 和 SubExpression (负责 减法 运算 ) 来 
实现 。 解 析 的 工作 完成 了 ， 我 们 还 需要 把 安排 运行 的 先后 顺序 (加 减 
法 不 用 考虑 ， 但 是 乘除 法 昵 ? 注意 扩展 性 ) ， 并 且 还 要 返回 结果 ， 因 
此 我 们 需要 增加 一 个 封装 类 来 进行 封装 处 理 ， 由 于 我 们 只 做 运算 ， 暂 
时 还 不 与 业务 有 关联 ， 定 义 为 Calculator 类 。 分 析 到 这 里 ， 思 路 就 比较 
清晰 了 ， 优 化 后 加 减法 类 图 如 图 27-2 所 示 。 


Calculator 的 作用 是 封 竣 ， 根 据 迪 米 特 法 则 ，Client 只 与 直接 的 朋友 
Calculator 交 流 ， 与 其 他 类 没关系 。 整 个 类 图 的 结构 比较 清晰 ， 下 面 填 
充 类 图 中 的 方法 ， 完 整 类 图 如 图 27-3 所 示 。 


类 图 已 经 完成 ， 下 面 来 看 代码 实现 。Expression 抽 象 类 如 代码 清单 
27-1 所 示 。 
代码 清单 27-1 抽象 表达 式 类 


public abstract class Expression { 


// 解 析 公 式 和 数值 ， 其 中 var 中 的 key 值 是 公式 中 的 参数 ，value 值 是 具体 的 数 


a 


public abstract int interpreter(HashMap<String,Integer> 
Var ) ; 


VarExpression 
| 
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运算 元 素 解析 


图 27-2 优化 后 加 减法 类 图 


Client 


+Calculator(String expStr) 
+run(HashMap<String, Integer> var) 


Expression 


tint interpreter(HashMap<String, Integer> var) 
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RE #Expression left 
+int Interpreter(Hash Map<String, Integer> var) 


#Expression right 


+SymbolExpression(Expression _left, Expression Tight) 


SubExpression AddExpression 
+int interpreter(HashMap<String, Integer> var) | | +int interpreter(Hash Map<String, Integer> var) 


图 27-3 完整 加 减法 类 图 


抽象 类 非常 简单 ， 仅 一 个 方法 interpreter 负 责 对 传递 进来 的 参数 和 
值 进 行 解析 和 匹配 ， 其 中 输入 参数 为 HashMap 类 型 ，key 值 为 模型 中 的 


数 ， 如 a、b、c 等 ，value 为 运算 时 取得 的 具体 数字 。 


党 


变量 解析 器 如 代码 清单 27-2 所 示 。 
代码 清单 27-2 变量 解析 器 


public class VarExpression extends Expression { 
private String key; 


public VarExpression(String _key)t{ 
this.key = _key; 

} 

// 从 map 中 取 之 


public int interpreter(HashMap<String, Integer> var) { 
return var.get(this.key); 


抽象 运算 符号 解析 器 如 代码 清单 27-3 所 示 。 


代码 清单 27-3 抽象 运算 符号 解析 器 


public abstract class SymbolExpression extends Expression { 
protected Expression left,; 
protected Expression right; 
// 所 有 的 解析 公式 都 应 只 关心 自己 左右 两 个 表达 式 的 结果 


public SymbolExpression(Expression _left,Expression _right) 


this, left = _left; 
this.right = _right; 


这 个 解析 过 程 还 是 比较 有 意思 的 ， 每 个 运算 符号 都 只 和 自己 左右 
两 个 数字 有 关系 ， 但 左右 两 个 数字 有 可 能 也 是 一 个 解析 的 结果 ， 无 论 
何 种 类 型 ， 都 是 Expression 的 实现 类 ， 于 是 在 对 运算 符 解 析 的 子 类 中 增 
加 了 一 个 构造 函数 ， 传 递 左右 两 个 表达 式 。 上 有 具体 的 加 、 减 法 解析 器 如 
代码 清单 27-4、 代 码 清单 27-5 所 示 。 


代码 清单 27-4 加 法 解析 器 


public class AddExpression extends SymbolExpression { 
public AddExpression(Expression _left,Expression _right){ 
super(_left,_right); 
} 


// 把 左右 两 个 表达 式 运算 的 结果 加 起 来 
public int interpreter(HashMap<String, Integer> var) { 
return super.left.interpreter(var) + 
super.right.interpreter(var); 


} 


代码 清单 27-5 减法 解析 器 


public class SubExpression extends SymbolExpression { 
public SubExpression(Expression _left,Expression _right){ 
super(_left,_right); 
} 


// 左 右 两 个 表达 式 相 减 
public int interpreter(HashMap<String, Integer> var) { 


return super.left.interpreter(var) - 
super.right.interpreter(var); 


解析 器 的 开发 工作 已 经 完成 了 ， 但 是 需求 还 没有 完全 实现 。 我 们 
还 需要 对 解析 器 进行 封装 ， 封 装 类 Calculator 如 代码 清单 27-6 所 示 。 


代码 清单 27-6 解析 作 封 装 类 


public class Calculator { 
// 定 义 表达 式 
private Expression expression; 
// 构 造 函 数 传 参 ， 并 解析 
public Calculator(String expStr)t{ 
// 定 义 一 个 栈 ， 安 排 运 算 的 先后 顺序 
Stack<Expression> Stack = new Stack<Expression>(); 
// 表 达 式 拆 分 为 字符 数组 
char[] charArray = expStr.toCcharArray( ); 
// 运 算 
Expression left = null; 
Expression right = null; 
for(int i=0;i<charArray.length;i++){ 
switch(charArray[i]) { 
case '+':; // 加 法 
// 加 法 结果 放 到 栈 中 
left = stack.pop(); 
right=new 
VarExpression(String.valueof(charArray[++i])); 
stack.push(new 
AddExpression(left,right)); 
break; 
Case '-': 
left = stack.pop(); 


right=new 
VarExpression(String.valueOof(charArray[++i])); 

stack.push(new 
SubExpression(left,right)); 

break; 

default: // 公 式 中 的 变量 

stack.push(new 

VarExpression(String.valueof(charArray[i]))); 


// 把 运算 结果 抛 出 来 


this.expression = stack.pop(); 


} 
// 开 始 运 算 
public int run(HashMap<String,Integer> var)t{ 

return this.expression.interpreter(var); 
} 


方法 比较 长 ， 我 们 来 分 析 一 下 ，Calculator 构 造 画 数 接收 一 个 表达 
式 ， 然 后 把 表达 式 转化 为 char 数 组 ， 并 判断 运算 符号 ， 如 果 是 “+? 则 进 
行 加 法 运算 ， 把 左边 的 数 (eft 变 量 ) 和 右边 的 数 right 变量 ) 加 起 来 
就 可 以 了 ， 那 左边 的 数 为 什么 是 在 栈 中 呢 ? 例如 这 个 公式 : at+b-c， 根 
据 for 循 环 ， 首 先 被 压 入 栈 中 的 应 该 是 有 a 元 素 生 成 的 VarExpression 对 
象 ， 然 后 判断 到 加 号 时 ， 把 a 元 素 的 对 象 VarExpression 从 栈 中 弹出 ， 与 
右边 的 数组 b 进 行 相 加 ，b 又 是 怎么 得 来 的 呢 ? 当 前 的 数组 游标 下 移 一 
个 单元 格 即 可 ， 同 时 为 了 防止 该 元 素 再 次 被 过 历 ， 则 通过 ++i 的 方式 跳 
过 下 一 个 遍历 一 一 于 是 一 个 加 法 的 运行 结束 。 减 法 也 采用 相同 的 运行 
原理 。 


为 了 满足 业务 要 求 ， 我 们 设置 了 一 个 Client 类 来 模拟 用 户 情 况 ， 用 
户 要 求 可 以 扩展 ， 可 以 修改 公式 ， 那 下 通 过 接收 键盘 事件 来 处 理 ， 


Client 类 如 代码 清单 27-7 所 示 。 


代码 清单 27-7 客户 模拟 类 


public class Client { 
// 运 行 四 则 运算 
public static void main(String[] args) throws IOExceptiont{ 
String expStr = getExpStr(); 
// 赋 值 
HashMap<String, Integer> var = getValue(expStr ) ， 
Calculator cal = new Calculator(expStr ) ，; 
System.out .println(" 运 算 结 果 为 : "+expStr 
+"="+Ccal.run(var)); 


// 获 得 表达 式 
public static String getExpStr() throws IOException{ 
System.out.print(" 请 输入 表达 式 : ")， 
return (new BufferedReader(new 
InputStreamReader(System.in))).readLine(); 


} 
// 获 得 值 映射 
public static HashMap<String, Integer> getValue(String 
exprStr) throws IOExceptiont{ 
HashMap<String, Integer> map = new 
HashMap<String,Integer>(); 
// 解 林 有 几 个 参数 要 传递 
for(char ch:exprSstr.tocCcharArray())t{ 
if(ch != '+' && ch != '-')t{ 
// 解 决 重复 参数 的 问题 
if(!'map.containskey(String.valueof(ch)))t{ 
String in = (new BufferedReader (new 
InputStreamReader (System.in))).readLine(); 


map.put(String.valueof(ch),Integer.valueOof(in)); 
} 


} 


return map; 


其 中 ，getExpStr 是 从 键 姐 事件 中 获得 的 表达 式 ，getValue 方 法 是 从 
键盘 事件 中 获得 表达 式 中 的 元 素 映 射 值 ， 运 行 过 程 如 下 。 


。 首先 ， 要 求 给 入 公式 。 
请 输入 表达 式 ，a+tb-c 

。 其 次 ， 要 求 输入 公式 中 的 参数 。 
请 输入 a 的 值 ，100 


请 输入 b 的 值 ，20 


请 输入 c 的 值 :40 


结果 为 : a+b-c=80 


看 ， 要 求 输入 一 个 公式 ， 然 后 输入 参数 ， 运 行 结 来 出 来 了 ! 那 我 
们 是 不 是 可 以 修改 公式 ? 当然 可 以 ， 我 们 只 要 输入 公式 ， 然 后 输入 相 
应 的 值 束 可 以 了 ， 公 式 是 在 运行 时 定义 的 ， 而 不 是 在 运行 前 殊 制 定好 
的 ， 是 不 是 类 似 于 初中 学 过 的 “代数 ”这 门 谋 ? 先 公 式 ， 然 后 赋值 ， 运 
算出 结果 。 


需求 已 经 开发 完毕 ， 公 式 可 以 自由 定义 ， 只 要 符合 规则 (有 变量 
有 运算 符合 ) 就 可 以 运算 出 结果 ; 若 需 要 扩展 也 非常 容易 ， 只 要 增加 
SymbolExpression 的 子 类 就 可 以 了 ， 这 束 是 解释 器 模式 。 


27.2 解释 大 模式 的 定义 


解释 器 模式 〈Interpreter Pattern) 是 一 种 按照 规定 语法 进行 解析 的 
方案 ， 在 现在 项 目 中 使 用 较 少 ， 其 定义 如 下 : Given a language, define a 


representation for its grammar along with an interpreter that uses the 
representation to interpret sentences in the language. (给 定 一 门 语言 ， 害 
义 它 的 文法 的 一 种 表示 ， 并 定义 一 个 解释 絮 ， 该 解释 右 使 用 该 表示 来 
解释 语言 中 的 句子 。) 


解释 紫 模 式 的 通用 类 图 如 图 27-4 所 示 。 


AbstractExpression 


| 
+Interpret() 


Client 


TerminalExpression NonterminaltExpression 


图 27-4 解释 右 模 式 通用 类 图 


抽象 解释 器 


e@ AbstractExpression 


具体 的 解释 任务 由 各 个 实现 类 完成 ， 具 体 的 解释 器 分 别 由 


TerminalExpression 和 Non-terminalExpression 完 成 。 


终结 符 表达 式 


® TerminalExpression 


实现 与 文法 中 的 元 素 相 关联 的 解释 操作 ， 通 党 一 个 解释 器 模式 中 
只 有 一 个 终结 人 符 表达 式 ， 但 有 多 个 实例 ， 对 应 不 同 的 终结 人 行 。 具 体 到 
我 们 例子 就 是 VarExpression 类 ， 表 达 式 中 的 每 个 终结 符 都 在 栈 中 产生 了 
一 个 VarExpression 对 象 。 


e NonterminalExpression 


文法 中 的 每 条 规则 对 应 于 一 个 非 终结 表达 式 ， 具 体 到 我 们 的 例子 
就 是 加 减法 规则 分 别 对 应 到 AddExpression 和 SubExpression 两 个 类 。 非 
终结 符 表 达 式 根据 逻辑 的 复杂 程度 而 增加 ， 原 则 上 每 个 文法 规则 都 对 


应 一 个 非 终结 符 表 达 式 。 


环境 角色 


@ Context 


具体 到 我 们 的 例子 中 是 采用 HashMap 代 蕉 。 


解释 瑚 是 一 个 比较 少 用 的 模式 ， 以 下 为 其 通用 源码 ， 可 以 作为 参 
考 。 抽 象 表达 式 通 常 只 有 一 个 方法 ， 如 代码 清单 27-8 所 示 。 


代码 清单 27-8 抽象 表达 式 


public abstract class Expression { 
// 每 个 表达 式 必须 有 一 个 解析 任务 
public abstract Object interpreter(Context ctx); 


抽象 表达 式 是 生成 语法 集合 〈 也 叫做 语法 树 ) 的 关键 ， 每 个 语法 
集合 完成 指定 语法 解析 任务 ， 它 是 通过 递归 调用 的 方式 ， 最 终 由 最 小 
的 语法 单元 进行 解析 完成 。 终 结 符 表 达 式 如 代码 清单 27-9 所 示 。 


代码 清单 27-9 终结 符 表 达 式 


public class TerminalExpression extends Expression { 
// 通 常 终结 符 表 达 式 只 有 一 个 ， 但 是 有 多 个 对 象 
public Object interpreter(Context ctx) { 
return null; 
} 


通 闸 ， 终 结 符 表 达 式 比较 简单 ， 主 要 是 处 理 场 景 元 素 和 数据 的 转 
换 。 


非 终结 符 表 达 式 如 代码 清单 27-10 所 示 。 


代码 清单 27-10 非 终结 从 表达 式 


public class NonterminalExpression extends Expression { 
// 每 个 非 终 结 符 表达 式 都 会 对 其 他 表达 式 产 生 依赖 
public NonterminalExpression(Expression... expression)t{ 


} 

public Object interpreter(Context ctx) { 
// 进 行文 法 处 理 
return null; 


I 


每 个 非 终结 符 表达 式 都 代表 了 一 个 文法 规则 ， 并 且 每 个 文法 规则 
都 只 关心 自己 周边 的 文法 规则 的 结果 (注意 是 结果 ) ， 因 此 这 就 产生 
了 每 个 非 终 结 符 表达 式 调用 自己 周边 的 非 终结 符 表达 式 ， 然 后 最 终 、 
最 小 的 文法 规则 就 是 终结 符 表 达 式 ， 终 结 符 表 达 式 的 概念 就 是 如 此 ， 
不 能 够 再 参与 比 自己 更 小 的 文法 运算 了 。 


客户 类 如 代码 清单 27-11 所 示 。 


代码 清单 27-11 客户 类 


public class Client { 
public static void main(String[] args) { 
Context ctx = new Context(); 
// 通 常 定 一 个 语法 容器 ， 容 纳 一 个 具体 的 表达 式 ， 通 常 为 ListArray、 
LinkedList、Stack 等 类 型 
Stack&Expression> Stack = null; 
for(;;)t 
// 进 行 语法 判断 ， 并 产生 递归 调用 


} 

// 产 生 一 个 完整 的 语法 树 ， 由 各 个 具体 的 语法 分 析 进 行 解析 
Expression exp = stack.pop(); 

// 具 体 元 素 进 入 场景 

exp.interpreter(ctx); 


通常 Client 古 一 个 封 狠 类 ， 封 泛 的 结果 束 古 传递 进来 一 个 规范 语法 
文件 ， 解 析 需 分析 后 产生 结 打 并 返回 ， 避 免 了 调用 者 与 语法 解析 融 的 
硝 合 关系 。 


27.3 解释 瑚 模式 的 应 用 
27.3.1 解释 硕 模 式 的 优点 


解释 硕 是 一 个 简单 语法 分 析 工 具 ， 它 最 显著 的 优点 束 是 扩展 性 ， 
修改 语法 规则 只 村 修改 相应 的 非 终结 符 表 达 式 殉 可 以 了 ， 者 扩展 语 
法 ， 则 只 要 增加 非 终结 符 类 就 可 以 了 。 


27.3.2 解释 万 模 式 的 缺点 


e 解释 右 模 式 会 引起 类 脱 且 


每 个 语法 都 要 产生 一 个 非 终结 符 表达 式 ， 语 法 规则 比较 复杂 时 ， 
就 可 能 产生 大 量 的 类 文件 ， 为 维护 带 来 了 非常 多 的 麻烦 。 


e 解释 句 模 式 采 用 递归 调用 方法 


每 个 非 终结 符 表 达 式 只 关心 与 目 己 有 关 的 表达 式 ， 每 个 表达 式 需 
要 知道 最 终 的 结果 ， 必 须 一 层 一 层 地 剥 晶 ， 无 论 是 面向 过 程 的 语言 还 
征 面 问 对 象 的 语言 ， 递 归 都 是 在 必要 条 件 下 使 用 的 ， 它 导致 调试 非常 
复杂 。 想 想 看 ， 如 果 要 排查 一 个 语法 错误 ， 我 们 是 不 是 要 一 个 断 点 一 
个 断 点 地 调试 下 去 ， 直 到 最 小 的 语法 单元 。 


pd 


。 效 率 问题 


解释 硕 模 式 由 于 使 用 了 大 量 的 循环 和 递归 ， 效 率 是 一 个 不 容 忽视 
的 问题 ， 特 别 是 一 用 于 解析 复 洒 、 克 长 的 语法 时 ， 效 率 是 难以 丸 受 
Hs 


27.3.3 解释 句 模 式 使 用 的 场景 


e 重复 发 生 的 问题 可 以 使 用 解释 器 模式 


例如 ， 多 个 应 用 服务 右 ， 每 天 产生 大 量 的 日 志 ， 需 要 对 日 志文 件 
进行 分 析 处 理 ， 由 于 各 个 服务 需 的 日 志 格 式 不 同 ， 但 走 数 据 有 要素 是 相 
同 的 ， 按 照 解 释 句 的 说 法 就 古 终结 符 表 达 式 都 征 相 同 的 ， 但 是 非 终结 
从 表达 式 谍 需要 制定 了 。 在 这 种 情况 下 ， 可 以 通过 程序 来 一 劳 永 逸 地 
解决 该 问题 。 


e 一 个 简单 语法 需要 解释 的 场景 


为 什么 是 简单 ” 看 看 非 终结 表达 式 ， 文 法 规则 越 多 ， 复 杂 度 越 
高 ， 而 且 类 间 还 要 进行 递归 调用 (看 看 我 们 例子 中 的 栈 ) 。 想 想 看 ， 
多 个 类 之 间 的 调用 你 需要 什么 样 的 耐心 和 信心 去 排查 问题 。 因 此 ， 解 
释 器 模式 一 般 用 来 解析 比较 标准 的 子 符 集 ， 例 如 SQL 语 法 分 析 ， 不 过 
部 分 逐渐 被 专用 工具 所 取代 。 


二 


该 


在 某 些 特 用 的 商业 环境 下 也 会 采用 解释 器 模式 ， 我 们 刚刚 的 例子 
忠 古 一 个 商业 环境 ， 而 且 现 在 模型 运算 的 例子 非常 多 ， 目 前 很 多 商业 
机 构 已 经 能 够 提供 出 大 量 的 数据 进行 分 析 。 


27.3.4 解释 器 模式 的 注意 事项 


尽量 不 要 在 重要 的 模块 中 使 用 解释 器 模式 ， 否 则 维护 会 是 一 个 很 
大 的 问题 。 在 项 目 中 可 以 使 用 shell、JRuby、Groovy 等 脚本 语言 来 代替 
解释 器 模式 ， 弥 补 Java 编 译 型 语言 的 不 足 。 我 们 在 一 个 银行 的 分 析 型 
项 目 中 就 采用 JRuby 进 行 运算 处 理 ， 避 免 使 用 解释 器 模式 的 四 则 运 
算 ， 效 率 和 性 能 各 方面 表现 良好 。 


27.4 最 佳 实践 


解释 器 模式 在 实际 的 系统 开发 中 使 用 得 非常 少 ， 因 为 它 会 引起 歼 
率 、 性 能 以 及 维护 等 问题 ， 一 般 在 大 中 型 的 框架 型 项 目 能 够 找到 它 的 
影 ， 如 一 些 数 据 分 析 工 具 、 报 表 设 计 工具 、 科 学 计算 工具 等 ， 若 你 
确实 过 到 “一 种 特定 类 型 的 问题 发 生 的 频率 足够 高 ?的 情况 ， 准 备 使 用 
解释 器 模式 时 ， 可 以 考虑 一 下 Expression4J、MESP (Math Expression 
String Parser) 、Jep 等 开源 的 解析 工具 包 (这 三 个 开源 产品 都 可 以 通过 
百度 、Google 搜 索 到 ， 请 读者 自行 查询 ， 功 能 都 异常 强大 ， 而 且 非 
常 容易 使 用 ， 效 率 也 还 不 错 ， 实 现 大 多 数 的 数学 运算 完全 没有 问题 ， 
目 己 没 有 必要 从 头 开 始 编写 解释 器 。 有 人 已 经 建立 了 一 条 康 庄 大 道 ， 
何必 再 走 目 己 的 泥 尝 小 路 呢 ? 


第 28 章 ”至 元 模式 


28.1 内 存 洲 出 ， 司 空 见 惯 


下 党， 我 正在 开会 电 ， 芭 人 机 | ] 进 来。 


“三 儿 ， 出 来 一 下 。” 


我 刚 出 会 议 室 门口 ， 老 大 束 发 话 了 。 


“ 即 当 ( 姓 朗 ， 顺 口 束 叫 郎 当 ) 的 那个 报考 系统 又 crash 了 一 台 机 
带 ， 两 天 已 经 宕 了 4 次 了， 你 这 边 还 有 紧急 的 事情 没有 ? .……. 没有 ， 那 
赶快 过 去 顶 一 下 ， 就 运行 三 天 的 程序 ， 两 天 宇 了 4 次 ， 还 怎么 玩 ? 1 ” 


我 马上 收拾 东西 ， 冲 到 马路 上 拦 了 出 租车 ， 同 时 打 电话 给 郎 当 。 


“二 哥 ， 上 商人 员 已 经 定位 出 了 ，OutOfMemory 内 存 盗 出， 没 查 到 
有 内 存 洪 漏 的 情况 ， 现 在 还 在 跟 踩 .…… 是 突然 又 涨 的 ， 都 是 在 党 忙 期 
出 现 问题 的 .……. 


内 存 洲 出 对 Java 应 用 来 说 实在 是 太平 第 了 ， 有 以 下 两 种 可 能 。 


e 内 和 存 泄漏 


无 意识 的 代码 缺陷 ， 导 致 内 存 泄漏 ，JVM 不 能 获得 连续 的 内 存 空 
间 。 


e@ 对 象 太 多 


代码 写 得 很 代 ， 产 生 的 对 象 太 多 ， 内 存 被 耗 尽 。 现 在 的 情况 是 没 
有 内 存 泄漏 ， 那 只 有 一 种 原因 一 一 代码 太 差 把 内 存 耗 尽 。 


到 现场 后 ， 即 当 给 我 介绍 了 一 下 系统 情况 。 该 系统 是 一 个 报考 系 
统 ， 其 中 有 一 个 模块 负责 社会 人 员 报 名 ， 该 模块 对 全 国 的 考试 人 员 只 
开放 3 天 ， 并 且 限 制 报 考 人 员 数 量 。 第 一 天 9 点 开始 报考 ， 系 统 慢 得 像 
蜗牛 ， 基 本 上 都 不 能 访问 ， 后 来 设置 了 HTTP Server 的 并 发 数量 ， 稍 有 
缓解 ，40 分 钟 后 宕 了 一 台 机 器 ，10 分 钟 后 ， 又 挂 了 一 台 ， 下 午 3 点 又 挂 

了 一 台 ， 看 样子 晚上 要 让 郎 当 去 寺庙 烧 烧 香 了 。 


该 系统 一 共有 8 台 应 用 服务 器 ， 基 本 上 CPU 繁 忙 程度 都 在 60% 以 
上 ，HTTP 的 最 大 并 发 是 2000， 平 均 分 配 到 每 台 应 用 服务 器 上 没有 太 大 
的 压力 ， 于 是 怀疑 是 代码 问题 ， 然 后 详细 了 人 解 了 一 下 业务 和 数据 流 逻 
辑 ， 基 本 的 业务 操作 过 程 清楚 了 ， 先 登录 (没有 账号 的 ， 则 要 先 注 
册 ) ， 登 录 后 ， 需 要 填写 以 下 信息 : 


e 考试 科目 ， 选 择 框 。 


e 考试 地 点 ， 选 择 框 ， 根 据 科 目 不 同 ， 列 表 不 同 。 


e 准 考证 邮寄 地 址 ， 输 入 框 。 


还 有 其 他 一 堆 信 息 ， 我 们 以 这 三 者 作为 代表 来 讲解 。 信 息 填 写 完 
毕 后 ， 点 击 确认 ， 报 名 就 结束 了 。 人 简单 程序 的 业务 逻辑 也 确实 古 这 
样 ， 为 什么 出 现 Crash 情 况 呢 ? 那 肯 定 古 和 压力 有 关系 ! 


我 们 先 把 这 个 过 程 的 静 仿 类 图 画 出 来 ， 如 图 28-1 所 示 。 
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图 28-1 报考 系统 类 图 


很 简单 的 工厂 方法 模式 ， 表 现 层 通过 工厂 方法 模式 创建 对 象 ， 然 
后 传递 给 业务 层 和 持久 层 ， 最 终 保存 到 数据 库 中 ， 为 什么 要 使 用 工厂 
方法 模式 而 不 用 直接 new 一 个 对 象 呢 ?因为 是 在 框架 下 编程 ， 必 须 有 一 


个 对 象 工 厂 《ObjectFactory Spring 也 有 对 象 工厂 ) 。 我 们 先 来 看 报考 信 
上 县， 如 代码 请 单 28-1 所 示 。 


代码 清单 28-1 报考 信息 


public class SignInfo { 
// 报 名 人 员 的 ID 
private String id; 
// 考 试 地 点 
private String location; 
// 考 试 科目 
private String subject; 
// 邮 寄 地 址 
private String postAddress ; 
public String getId() { 

return id; 


} 
public void setId(String id) { 
this.id = id; 


public String getLocation() { 
return location; 


public void setLocation(String location) { 
this.location = location; 


} 
public String getSubject() { 
return subject; 


public void setSubject(String subject) { 
this.subject = subject; 


} 
public String getPostAddress() { 
return postAddress ; 


public void setPostAddress(String postAddress) { 
this.postAddress = postAddress; 
} 


它 是 一 个 很 简单 的 POJO 对 象 (Plain Ordinary Java Object， 简 单 
Java 对 象 ) 。 我 们 再 来 看 工厂 类 ， 如 代码 清单 28-2 所 示 。 


代码 清单 28-2 报考 信息 工 


public class SignInfoFactory { 
// 报 名 信息 的 对 象 工厂 
public static SignInfo getSignInfo(){ 
return new SignInfo(); 
} 


工厂 类 或 这 么 简单? 非 也 ， 这 是 我 们 的 教学 代码 ， 真 实 的 
ObjectFactory 要 复杂 得 多 ， 主 要 是 注入 了 部 分 Handler 的 管理 。 表 现 层 
是 如 何 创建 对 象 的 ， 如 代码 清单 28-3 所 示 。 


代码 清单 28-3 场景 类 


public class Client { 
public static void main(String[] args) { 
// 从 工厂 中 获得 一 个 对 象 
SignInfo signInfo = SignInfoFactory.getSignInfo( ) ， 
// 进 行 其 他 业务 处 理 


就 这 么 简单 ， 但 是 简单 为 什么 会 出 现 问题 呢 ? 而 且 这 样 写 也 没有 
问题 呀 ， 很 标准 的 工厂 方法 模式 ， 应 该 不 会 有 大 问题 ， 然 后 又 看 了 看 
系统 厂商 提供 的 分 析 报 告 ， 报 告 中 指出 : 内 存 突然 由 800MB 妖 升 到 
1.4GB， 新 的 对 象 申 请 不 到 内 存 空 间 ， 于 是 出 现 OutOfMemory， 同 时 报 


告 中 还 列 出 宕 机 时 刻 内 存 中 的 对 象 ， 其 中 SignInfo 类 的 对 象 就 有 
400MB， 闫 子 ， 绝 对 是 关子 ! 报告 都 没有 看 嘛 ! 


问题 找到 了 ， 我 拉 郎 当 过 来 谈话 , “三 商 不 是 分 析出 原因 了 嘛 ， 人 
家 已 经 指出 SignInfo 类 的 对 象 占用 了 400MB 多 的 内 存 ， 这 是 怎么 回 
事 ? ” 


“三 哥 ， 这 是 很 正 前 的 ， 这 么 大 的 访问 量 ， 产 生出 这 么 多 的 
SignInfo 对 象 也 是 应 该 的 ， 内 存 中 有 这 么 多 对 象 并 不 表示 这 些 对 象 正在 
被 使 用 蚜 ， 售 计 很 大 一 部 分 还 没有 个 回 收 而 已 ， 垃 圾 回收 器 什么 时 候 
回收 内 存 中 的 对 象 这 是 不 确定 的 。 你 看 ， 并 发 200 多 个 ， 这 可 是 并 发 数 


我 想 了 想 ， 也 确实 是 这 么 回 事 。 既 然 已 经 定位 是 内 存 中 对 象 太 
多 ， 那 就 应 该 想到 使 用 一 种 共享 的 技术 减少 对 象 数量 ， 那 怎么 共 胖 
呢 ? 


大 家 知道 ， 对象 池 (Object Pool) 的 实现 有 很 多 开源 工具 ， 比 如 
Apache 的 commons-pool 丈 是 一 个 非常 不 错 的 池 工 具 ， 我 们 暂时 还 用 不 
到 这 种 重量 级 的 工具 ， 我 们 自己 来 设计 一 个 共享 对 象 池 ， 需 要 实现 如 
下 两 个 功能 。 


Js 村 日 


e 窑 锅 定义 


我 们 要 定义 一 个 池上 容器， 在 这 个 容器 中 容纳 哪些 对 象 。 
e 提供 客户 端 访 问 的 接口 


我 们 要 提供 一 个 接口 供 客户 端 访 问 ， 池 中 有 可 用 对 象 时 ， 可 以 直 
接 从 池 中 获得 ， 否 则 建立 一 个 新 的 对 象 ， 并 放置 到 池 中 。 


设计 思路 有 了 ， 那 我 们 池 中 对 象 的 标准 是 什么 呢 ? 你 想 想 看 ， 如 
果 你 把 所 有 的 对 象 都 放 到 池 中 ， 那 还 有 什么 意义 ? 内存 早 就 给 你 撑 爆 
了 1! 这 么 多 对 象 ， 必 然 有 一 些 相 同 的 属性 值 ， 如 几 十 万 SignInfo 对 象 
中 ， 考 试 科目 束 4 个 ， 考 试 地 点 也 就 是 30 多 个 ， 其 他 的 属性 则 是 每 个 对 
象 都 不 相同 的 ， 我 们 把 对 象 的 相同 属性 提取 出 来 ， 不 同 的 属性 在 系统 
内 进行 赋值 处 理 ， 是 不 是 就 可 以 建立 一 个 池 了 ? 话 无 须 多 说 ， 我 们 以 
类 图 来 表示 ， 如 图 28-2 所 示 。 
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图 28-2 增加 对 象 池 的 类 图 


做 一 个 很 小 的 改动 ， 增 加 了 一 个 子 类 ， 实 现 囊 缓冲 池 的 对 象 建 
立 ， 同 时 在 工厂 类 上 增加 了 一 个 容器 对 象 HashMap， 你 存 池 中 的 所 有 
对 象 。 我 们 先 来 看 产品 子 类 ， 如 代码 清单 28-4 所 示 。 


代码 清单 28-4 带 对 象 池 的 报考 信息 


public class SignInfo4Pool extends SignInfo { 
// 定 义 一 个 对 象 池 提 取 的 KEY 值 
private String key; 
// 构 造 画 数 获得 相同 标志 
public SignInfo4Pool(String _key)t{ 
this.key = _key; 


} 
public String getKey() { 
return key; 


} 

public void setkey(String key) { 
this.key = key; 

} 


很 简单 ， 就 是 增加 了 一 个 key 值 ， 为 什么 要 增加 key 值 ?为 什么 要 
使 用 子 类 ， 而 不 在 SignInfo 类 上 做 修改 ? 好 ， 我 来 给 你 解释 为 什么 要 这 
样 做 ， 我 们 刚刚 已 经 分 析 了 所 有 的 SignInfo 对 象 都 有 一 些 共 同 的 属性 : 
考试 科目 和 考试 地 点 ， 我 们 把 这 些 共性 提取 出 来 作为 所 有 对 象 的 外 部 
状态 ， 在 这 个 对 象 池 中 一 个 具体 的 外 部 状态 只 有 一 个 对 象 。 按 照 这 个 
设计 ， 我 们 定义 key 值 的 标准 为 : 考试 科目 + 考试 地 点 的 复合 字符 串 作 
为 唯一 的 池 对 象 标 准 ， 也 就 是 说 在 对 象 池 中 ， 一 个 key 值 唯一 对 应 一 个 
对 象 。 


注意 ”在 对 象 池 中 ， 对 象 一 旦 产生 ， 必 然 有 一 个 唯一 的 、 可 访问 
的 状态 标志 该 对 象 ， 而 且 池 中 的 对 和 象 声 明 周 期 是 由 池 容 器 决 是 ， 而 不 
是 由 使 用 者 决定 的 。 


你 可 能 马上 就 要 提出 了 ， 为 什么 不 建立 一 个 新 的 类 ， 包 含 subject 和 
location 两 个 属性 作为 外 部 状态 昵 ? 咽 ， 这 是 一 个 办 法 ， 但 不 是 最 好 的 
办 法 ， 有 两 个 原因 : 


e 修改 的 工作 量 太 大 ， 增 加 的 这 个 类 由 谁 来 创建 呢 ? 同 时 ， 
SignInfo 类 是 否 也 要 修改 呢 ? 你 不 可 能 让 两 段 相 同 的 POJO 程 序 同 时 出 
现在 同一 模块 中 吧 


e 性 能 问题 ， 我 们 会 在 扩展 模块 中 讲解 。 


说 了 这 么 多 ， 我 们 还 是 继续 来 看 程序 ， 工 厂 类 如 代码 清单 28-5 所 


修 ° 


代码 清单 28-5 带 对 象 池 的 工厂 类 


public class SignInfoFactory { 

// 池 容器 

private static HashMap<String,SignIinfo> pool = new 
HashMap<String,SignInfo>(); 

// 报 名 信息 的 对 象 工厂 

Q@Deprecated 

public static SignInfo( ){ 

return new SignInfo(); 


} 
// 从 池 中 获得 对 象 
public static SignInfo getSignInfo(String key)t{ 
// 设 置 返回 对 象 
SignInfo result = null; 
// 池 中 没有 该 对 象 ， 则 建立 ， 并 放 入 池 中 
if(!pool.containskey(key))t 
System.out.println(key + "---- 建 立 对 象 ， 并 放置 到 池 


result = new SignInfo4Pool(key ) ; 
pool.put(key, result); 
}elsef 


result = pool.get(key); 
System.out.println(key +"--- 直 接 从 池 中 取得 "); 


return result,; 


方法 都 很 简单 ， 不 多 解释 。 读 者 需要 注意 一 点 的 是 @Deprecated 注 
解 ， 不 要 有 删除 投产 中 代码 的 念 涉 ， 如 果 方 法 或 类 确实 不 再 使 用 了 ， 
增加 该 注解 ， 表 示 该 方法 或 类 已 经 过 时 ， 尽 量 不 要 再 使 用 了 ， 我 们 应 
该 保持 历史 原貌 ， 同 时 也 有 助 于 版 本 同 下 兼容 ， 特 别 是 在 产品 级 研发 
中 。 


我 们 再 来 看 看 客户 端 古 如 何 调用 的 ， 如 代码 清单 28-6 所 示 。 


代码 清单 28-6 场景 


public class Client { 
public static void main(String[] args) { 
// 初 始 化 对 象 池 
for(int i=0;i<4;i++){ 
String subject = "科目 " + 主 ; 
// 初 始 化 地 址 
for(int j=0;j<30;]j++){ 
String key = subject + "考试 地 点 "+j，; 
SignInfoFactory.getSignInfo(key); 


} 
SignInfo signInfo = SignInfoFactory.getSignInfo(" 科 目 1 


考试 地 点 1" ) ; 
} 
} 


运行 结果 如 下 所 示 : 


科目 3 考试 地 点 25---- 建 立 对 象 ， 并 放置 到 池 


科目 3 考试 地 点 26---- 建 立 对 象 ， 并 放置 到 池 中 
科目 3 考试 地 点 27---- 建 立 对 象 ， 并 放置 到 池 中 
科目 3 考试 地 点 28---- 建 立 对 象 ， 并 放置 到 池 中 
科目 3 考试 地 点 29---- 建 立 对 象 ， 并 放置 到 池 中 
科目 1 考试 地 点 1--- 直 接 从 池 中 取得 


前 面 还 有 很 多 的 对 象 创建 提示 语句 ， 不 再 复制 。 通 过 这 样 的 改造 
后 ， 我 们 想 想 内 存 中 有 多 少 个 SignInfo 对 象 ? 是 的 ， 最 多 120 个 对 象 ， 
相 比 之 前 几 万 个 SignInfo 对 象 优化 了 非常 多 。 细 心 的 读者 可 能 注意 到 了 
SignInfo4Pool 类 基本 上 没有 跑 出 我 们 的 视线 范围 ， 仅 仅 在 工矿 方法 中 使 
用 到 了 ， 尽 量 缩小 变更 引起 的 风险 ， 想 想 看 我 们 的 改动 是 不 是 很 小 ， 
只 要 在 展示 层 中 拼 一 个 字符 串 ， 然 后 传递 到 工厂 方法 中 就 可 以 了 。 


通过 这 样 的 改造 后 ， 第 三 天 系统 运行 得 非常 稳定 ，CPU 占 用 率 也 
下 降 了 ， 而 且 以 后 再 也 没有 出 现 类 似 问 题 ， 这 就 是 至 元 模式 的 功劳 。 


28.2 享 元 模式 的 定义 


享 元 模式 (Flyweight Pattern) 是 池 技术 的 重要 实现 方式 ， 其 定义 
如 下 : Use sharing to support large numbers of fine-grained objects 


efficiently. 《使 用 共 吾 对 象 可 有 效 地 文 持 大 量 的 细 粒 度 的 对 象 。) 


享 元 模式 的 定义 为 我 们 提出 了 两 个 要 求 : 细 粒 度 的 对 象 和 共享 对 
象 。 我 们 知道 分 配 太 多 的 对 象 到 应 用 程序 中 将 有 损 程序 的 性 能 ， 同 时 
还 容易 造成 内 存 洲 出 ， 那 怎么 避免 呢 ? 就 是 译 元 模式 提 到 的 共 译 技 
术 。 我 们 先 来 了 解 一 下 对 象 的 内 部 状态 和 外 部 状态 。 


要 求 细 粒度 对 象 ， 那 么 不 可 避免 地 使 得 对 象 数量 多 且 性 质 相近 ， 
那 我 们 避 ® 将 这 些 对 象 的 信息 分 为 两 个 部 分 ， 内 部 状态 (intrinsic) 与 外 


部 状态 (extrinsic) 。 


e 内 部 状态 


内 部 状态 是 对 象 可 共享 出 来 的 信息 ， 存 储 在 译 元 对 象 内 部 并 且 不 
会 随 环 境 改 变 而 改变 ， 如 我 们 例子 中 的 id、postAddress 等 ， 它 们 可 以 作 
为 一 个 对 象 的 动态 附加 信息 ， 不 必 直 接 储 存在 具体 某 个 对 象 中 ， 属 于 
可 以 共享 的 部 分 。 


e 外 部 状态 


外 部 状态 是 对 象 得 以 依赖 的 一 个 标记 ， 有 是 随 环境 改变 而 改变 的 、 


不 可 以 共享 的 状态 ， 如 我 们 例子 中 的 考试 科目 + 考试 地 点 复合 字符 串 ， 
它 是 一 批 对 象 的 统一 标识 


， 征 唯一 的 一 个 索引 值 。 


有 了 对 象 的 两 个 状态 
图 28-3 所 示 。 


， 我 们 束 可 以 来 看 享 元 模式 的 通用 类 图 ， 如 
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unsharedConcreteFlyweight 


= 
图 28-3 享 元 模式 的 通用 类 图 
类 图 也 很 简单 ， 我 们 先 来 看 我 们 享 元 模式 角色 名 称 


e Flyweight 一 一 抽象 享 元 角色 


它 简 单 地 说 可 是 一 个 产品 的 抽象 类 ， 同 时 定义 出 对 象 的 外 部 状态 


和 内 部 状态 的 接口 或 实现 。 


e ConcreteFlyweight 一 一 具体 享 元 角色 
具体 的 一 个 产品 类 ， 实 现 抽象 角色 定义 的 业务 。 该 角色 中 需要 注 


意 的 是 内 部 状态 处 理应 该 与 环境 无 关 ， 不 应 该 出 现 一 个 操作 改变 了 内 
部 状态 ， 同 时 修改 了 外 部 状态 ， 这 是 绝对 不 允许 的 。 


不 存在 外 部 状态 或 者 安全 要 求 (如 线程 安全 ) 不 能 够 使 用 共享 技 
术 的 对 象 ， 该 对 象 一 般 不 会 出 现在 享 元 工厂 中 。 


e FlyweightFactory 一 一 享 元 工厂 


职责 非常 简单 ， 融 是 构造 一 个 池 容 器 ， 同 时 提供 从 池 中 获得 对 象 
的 方法 。 


享 元 模式 的 目的 在 于 运用 共享 技术 ， 使 得 一 些 细 粒 度 的 对 象 可 以 
共享 ， 我 们 的 设计 确实 也 应 该 这 样 ， 多 使 用 细 粒 度 的 对 象 ， 便 于 重用 
或 重 构 。 我 来 看 享 元 模式 的 通用 代码 ， 先 看 抽象 享 元 角色 ， 如 代码 清 
单 28-7 所 示 。 


代码 清单 28-7 抽象 享 元 角色 


public abstract class Flyweight { 
// 内 部 状态 
private String intrinsic; 
// 外 部 状态 
protected final String Extrinsic; 
// 要 求 享 元 角色 必须 接受 外 部 状态 


public Flyweight(String _EXxtrinsic){ 
this.Extrinsic = _Extrinsic; 


} 

// 定 义 业 务 操作 

public abstract void operate() ; 

// 内 部 状态 的 getter/setter 

public String getIntrinsic() { 
return intrinsic,; 


public void setIntrinsic(String intrinsic) { 
this.intrinsic = intrinsic; 
} 


抽象 人 享 元 角色 一 般 为 抽象 类 ， 在 实际 项 目 中 ， 一 般 是 一 个 实现 
类 ， 它 是 描述 一 类 事物 的 方法 。 在 抽象 角色 中 ， 一 般 需 要 把 外 部 状态 
和 内 部 状态 (当然 了 ， 可 以 没有 内 部 状态 ， 只 有 行为 也 是 可 以 的 ) 定 
义 出 来 ， 避 人 免 子 类 的 随意 扩展 。 我 们 再 来 看 具体 的 享 元 角色 ， 如 代码 
清单 28-8 所 示 。 


代码 清单 28-8 具体 享 元 角色 


public class ConcreteFlyweight1 extends Flyweight{ 
// 接 受 外 部 状态 
public ConcreteFlyweight1i(String _Extrinsic)t{ 
super(_Extrinsic); 


} 

// 根 据 外 部 状态 进行 逻辑 处 理 

public void operate(){ 
// 业 务 逻 辑 

} 


} 
public class ConcreteFlyweight2 extends Flyweight{ 
// 接 受 外 部 状态 
public ConcreteFlyweight2(String _Extrinsic)t{ 
super(_Extrinsic); 


} 

// 根 据 外 部 状态 进行 逻辑 处 理 

public void operate(){ 
// 业 务 逻 辑 


这 很 简单 ， 实 现 目 己 的 业务 逻辑 ， 人 然后 接收 外 部 状态 ， 以 便 内 部 
业务 逻辑 对 外 部 状态 的 依赖 。 注 意 ， 我 们 在 抽象 各 元 中 对 外 部 状态 加 
上 了 final 关 键 字 ， 防 止 意外 产生 ， 什 么 意外 ? 获得 了 一 个 外 部 状态 ， 然 
后 无 意 修改 了 一 下 ， 池 就 宴 乱 了 |! 


注意 ”在 程序 开发 中 ， 确 认 只 需要 一 次 赋值 的 属性 则 设置 为 final 


类 型 ， 避 免 无 意 修改 导致 逻辑 混乱 ， 特 别 是 Session 级 的 常量 或 变量 。 


我 们 继续 看 享 元 工厂 ， 如 代码 清单 28-9 所 示 。 


代码 清单 28-9 享 元 工厂 


public class FlyweightFactory { 

// 定 义 一 个 池 容 器 

private static HashMap<String,Flyweight> pool= new 
HashMap<String,Flyweight>(); 


// 享 元 工厂 

public static Flyweight getFlyweight(String EXxtrinsic){ 
// 需 要 返回 的 对 象 
Flyweight flyweight = null; 
// 在 池 中 没有 该 对 象 


if(pool.containskKey(Extrinsic))t{ 
flyweight = pool.get(Extrinsic); 


// 根 据 外 部 状态 创建 部 元 对 象 

flyweight = new 
ConcreteFlyweight1(Extrinsic); 

// 放 置 到 池 中 

pool.put(Extrinsic, flyweight); 


}else 


} 
return flyweight; 


28.3 享 元 模式 的 应 用 
28.3.1 享 元 模式 的 优点 和 缺点 

享 元 模式 是 一 个 非常 简单 的 模式 ， 它 可 以 大 大 减少 应 用 程序 创建 
的 对 象 ， 降 低 程序 内 存 的 占用 ， 增 强 程 序 的 性 能 ， 但 它 同 时 也 提高 
系统 复杂 性 ， 需 要 分 离 出 外 部 状态 和 内 部 状态 ， 而 且 外 部 状态 具有 固 


化 特性 ， 不 应 该 随 内 部 状态 改变 而 改变 ， 否 则 导致 系统 的 逻辑 混乱 。 


28.3.2 享 元 模式 的 使 用 场景 


在 如 下 场景 中 则 可 以 选择 使 用 享 元 模式 。 


e 系统 中 存在 大 量 的 相似 对 和 象 。 


。 细 粒度 的 对 象 都 具备 较 接近 的 外 部 状态 ， 而 且 内 部 状态 与 环境 
无 关 ， 也 就 是 说 对 象 没 有 特定 身份 。 


e 需要 缓冲 池 的 场景 。 


28.4 至 元 模式 的 扩展 


28.4.1 线程 安全 的 问题 


线程 安全 是 一 个 老生 稼 谈 的 话题 ， 只 要 使 用 Java 开 发 都 会 遇 到 这 个 
问题 ， 我 们 之 所 以 要 在 今天 的 至 元 模式 中 提 到 该 问题 ， 是 因为 该 模式 
有 太 大 的 几率 发 生 线 程 不 安全 ， 为 什么 呢 ? 


我 们 还 以 报考 系统 为 例 来 说 明 这 个 问题 。 大 家 有 没有 想 过 ， 为 什 
么 要 以 考 斌 科目 + 考试 地 点 作为 外 部 状态 呢 ? 为 什么 不 能 以 考试 科目 或 
者 考试 地 点 作为 外 部 状态 呢 ? 这 样 池 中 的 对 象 会 更 少 ! 可 以 ! 完全 可 
以 ! 我 们 把 程序 以 考试 科目 为 外 部 状态 ， 把 享 元 工厂 稍 作 修 改 ， 如 代 
码 清 单 28-10 所 示 。 


代码 清单 28-10 报考 信息 工厂 


public class SignInfoFactory { 
// 池 容器 
private static HashMap<String,SignIinfo> pool = new 
HashMap<String,SignInfo>(); 
// 从 池 中 获得 对 象 
public static SignInfo getSignInfo(String key)t{ 
// 设 置 返回 对 象 
SignInfo result = null; 
// 池 中 没有 该 对 象 ， 则 建立 ， 并 放 入 池 中 
if(!pool.containskey(key))t 
result = new SignInfo( ); 
pool.put(key, result); 


}elsef 
result = pool.get(key); 


return result,; 


下 面 做 很 小 的 改动 ， 只 修改 了 黑色 字体 部 分 。 为 了 展示 多 线程 的 
情况 ， 我 们 写 一 个 多 线程 的 类 ， 如 代码 清单 28-11 所 示 。 


代码 清单 28-11 多 线程 场景 


public class MultiThread extends Thread { 
private SignInfo signIinfo; 
public MultiThread(SignInfo _signInfo)f{ 
this.SignInfo = _signInfo; 


public void run()t{ 


if(!signInfo.getId().equals(signIinfo.getLocation()))t{ 
System.out .println(" 编 
号 : "+SsignInfo.getId()); 
System.out.println(" 考 试 地 
址 : "+signInfo.getLocation()); 
System.out.println(" 线 程 不 安全 了 ! ") ， 
} 


在 run 方 法 中 判断 特殊 值 ， 检 查 是 否 是 线程 安全 ， 我 们 来 看 看 场景 
类 ， 如 代码 清单 28-12 所 示 。 


代码 清单 28-12 场景 类 


public class Client { 
public static void main(String[] args) { 

// 在 对 象 池 中 初始 化 4 个 对 象 
SignInfoFactory .getSignInfo(" 科 目 1 
SignInfoFactory ,getSignInfo(" 科 目 2 
SignInfoFactory ,getSignInfo(" 科 目 3' 
SignInfoFactory ,getSignInfo(" 科 目 4 


// 取 得 对 象 
SignInfo signInfo = SignInfoFactory,getSignInfo(" 科 


目 2" ) ， 

while(true)t{ 
signInfo.setId("ZhangSan"); 
signInfo.setLocation("ZhangSan"); 
(new MultiThread(signInfo)).start(); 
signInfo.setId("LiSi"),; 
signInfo.setLocation("LiSi"); 
(new MultiThread(signInfo)).start(); 


模拟 实际 的 多 线程 情况 ， 在 对 象 池 中 我 们 保留 4 个 对 象 ， 然 后 启动 
N 多 个 线程 来 模拟 ， 我 们 马上 束 看 到 如 下 的 提示 : 


二 出 宇 i EP 
编号 : LiSi 


考试 地 址 : ZhangSan 


线程 不 安全 了 1 


看 看 ， 线 程 不 安全 了 吧 ， 这 是 正常 的 ， 设 置 的 部 元 对 象 数量 太 
少 ， 导 致 每 个 线程 都 到 对 象 池 中 获得 对 象 ， 然 后 都 去 修改 其 属性 ， 于 
古 束 出 现 一 些 不 和 谐 数据 。 只 要 使 用 Java 开 发 ， 线 程 问题 是 不 可 如 人 多 
的 ， 那 我 们 怎么 去 避免 这 个 问题 呢 ? 至 元 模式 是 让 我 们 使 用 共享 技 
术 ， 而 Java 的 多 线程 又 有 如 此 问题 ， 该 如 何 设计 呢 ? 没什么 可 以 参考 的 
标准 ， 只 有 依靠 经 验 ， 在 需要 的 地 方 考虑 一 下 线程 安全 ， 在 大 部 分 的 
场景 下 都 不 用 考虑 。 我 们 在 使 用 享 元 模式 时 ， 对 象 池 中 的 享 元 对 象 尽 
量 多 ， 多 到 足够 满足 业务 为 止 。 


28.4.2 性 能 平衡 


尽量 使 用 Java 基 本 类 型 作为 外 部 状态 。 在 报考 系统 中 ， 我 们 不 考虑 
系统 的 修改 风险 ， 完 全 可 以 重新 建立 一 个 类 作为 外 部 状态 ， 因 为 这 才 
完全 符合 面向 对 象 编程 的 理念 。 好 ， 我 们 实现 处 理 ， 先 看 类 图 ， 如 图 
28-4 所 示 。 
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图 28-4 类 作为 外 部 状态 
我 们 首先 来 看 ExtrinsicState 外 部 状态 类 ， 如 代码 清单 28-13 所 示 。 
代码 清单 28-13 外 部 状态 类 


public class ExtrinsicState { 


// 考 斌 科 


private String subject; 
// 考 试 地 点 
private String location; 
public String getSubject() { 
return subject; 


} 
public void setSubject(String subject) { 
this.subject = subject; 


public String getLocation() { 
return location; 


public void setLocation(String location) { 
this.location = location; 


@Override 
public boolean equals(Object obj)t{ 
If(obj instanceof ExtrinsicState)t 
ExtrinsicState state = (ExtrinsicState)obj; 
return state.getLocation().equals(location) && 
state.getSubject().equals(subject); 
return false; 
@Override 


public int hashCode( ){ 
return subject.hashCode() + location.hashCode(); 
} 


注意 ,一定 要 禾 写 equals 和 hashCode 方 法 ， 否 则 它 作 为 HashMap 中 
的 key 值 是 根本 没有 意义 的 ， 只 有 hashCode 值 相等 ， 并 且 equals 返 回 结 
果 为 ttue， 两 个 对 象 才 相等 ， 也 只 有 在 这 种 情况 下 才 有 可 能 从 对 象 池 中 
查找 获得 对 象 。 


注意 ”如果 把 一 个 对 象 作 为 Map 类 的 键 值 ， 一 定 要 确保 重 写 了 
equals 和 hashCode 方 法 ， 否 则 会 出 现 通 过 键 值 搜索 失败 的 情况 ， 例 如 


map.get(object)、map.contains(object) 等 会 返回 失败 的 结果 。 


SignInfo 的 修改 较 小 ， 仅 在 SignInfo 中 引入 该 ExtrinsicState 外 部 状态 
对 象 ， 在 此 不 再 警 述 。 我 们 再 来 看 享 元 工厂 ， 它 是 以 ExtrinsicState 类 作 
为 外 部 状态 ， 如 代码 清单 28-14 所 示 。 


代码 清单 28-14 享 元 工厂 


public class SignInfoFactory { 
// 池 容器 
private static HashMap<ExtrinsicState,SignIinfo> pool = new 
HashMap <ExtrinsicState,SignInfo>(); 
// 从 池 中 获得 对 象 
public static SignInfo getSignInfo(ExtrinsicState key)t{ 
// 设 置 返回 对 象 
SignInfo result = null; 
// 池 中 没有 该 对 象 ， 则 建立 ， 并 放 入 池 中 
If(!pool.containsKey(Kkey) ){ 
result = new SignInfo( ) ; 
pool.put(key, result); 


}elsef 
} 


return result,; 


result = pool.get(key); 


重点 是 看 看 我 们 的 场景 类 ， 我 们 来 测试 一 下 性 能 差异 ， 如 代码 清 
单 28-15 所 示 。 


代码 清单 28-15 场景 类 


public class Client { 
public static void main(String[] args) { 
// 初 始 化 对 象 池 
ExtrinsicState State1 = new ExtrinsicState(); 
state1,setSsubject(" 科 目 1")， 
state1,setLocation(" 上 海 ") ， 
SignInfoFactory .getSignInfo(Sstate1) 


EXxtrinsicState state2 = new EXxtrinsicState(); 

state2,setSubject(" 科 目 1" ) ， 

state2 ,setLocation(" 上 海 ") ， 

// 计 算 执 行 100 万 次 需要 的 时 间 

long currentTime = System.currentTimeMillis(); 

for(int i=0;i<1000000;i++){ 
SignInfoFactory.getSignInfo(state2); 


long tailTime = System.currentTimeMillis(); 
System.out .println(" 执 行 时 间 : "+(tailTime - 
currentTime) + " ms"); 


} 


ww 


运行 结果 如 下 所 示 : 
执行 时 间 : 172 ms 


同样 ， 我 们 看 看 以 String 类 型 作为 外 部 状态 的 运行 情况 ， 如 代码 清 
单 28-16 所 示 。 


代码 清单 28-16 场景 


public class Client { 
public static void main(String[] args) { 
String key1 =" 科 有 日 1 上 海 "， 
String key2 = "科目 1 上 海 " ; 
// 初 始 化 对 象 池 
SignInfoFactory .getSignInfo(key1) ; 
// 计 算 执行 10 万 次 需要 的 时 间 
long currentTime = System.currentTimeMillis(); 
for(int i=0;i<10000000;i++)f{ 
SignInfoFactory.getSignInfo(key2 ) ; 


long tailTime = System.currentTimeMillis(); 
System.out.printlin(" 执 行 时 间 : "+(tailTime - 
currentTime) + " ms"); 


} 
} 


运行 结果 如 下 所 示 : 

执行 时 间 : 78 ms 

看 到 没 ? 一 半 的 效率 ， 这 还 是 非常 简单 的 享 元 对 象 ， 看 看 我 们 重 
写 的 equals 方 法 和 hashCode 方 法 ， 这 段 代码 是 必须 实现 的 ， 如 果 比 较 复 


杂 ， 这 个 时 间 差 异 会 更 大 。 


各 位 ， 想 想 看 ， 使 用 自己 编写 的 类 作为 外 部 状态 ， 必 须 覆 写 equals 
方法 和 hashCode 方 法 ， 而 且 执 行 效率 还 比较 低 ， 这 种 吃力 不 讨好 的 事 
情 最 好 别 做 ， 外 部 状态 最 好 以 Java 的 基本 类 型 作为 标志 ， 如 String 、int 
等 ， 可 以 大 幅 地 提升 效率 。 


28.5 最 佳 实践 


Flyweight 是 拳击 比赛 中 的 特 用 名 词 ， 意 思 是 “ 特 轻 量 级 ”， 指 的 是 
51 公 斤 级 比赛 ， 用 到 设计 模式 中 是 指 我 们 的 类 要 轻 量 级 ， 粒 度 要 人 小， 
这 才 是 它 要 表达 的 意思 。 粒 度 小 了 ， 市 来 的 问题 式 古 对 象 太 多 ， 那 整 
用 共有 至 技术 来 解决 。 


诗 元 模式 在 Java API 中 也 是 随处 可 见 ， 如 这 样 的 程序 束 古 一 个 很 
好 的 例子 ， 如 代码 清单 28-17 所 示 。 


代码 清单 28-17 API 中 的 享 元 模式 


public class Test { 

public static void main(String[] args) { 
String strl = 
String str2 = 2 
String str3 = 
String str4; 
str4 = stri + str2; 
System.out.println(str3 == str4); 
str4 = (stri + str2).intern(); 
System.out.println(str3 == str4); 


看 看 Java 的 帮助 文件 中 String 类 的 intern 方 法 。 如 果 是 String 的 对 象 
池 中 有 该 类 型 的 值 ， 则 直接 返回 对 象 池 中 的 对 象 ， 那 当然 相等 了 。 


需要 说 明 一 下 的 是 ， 虽 然 可 以 使 用 至 元 模式 可 以 实现 对 象 池 ， 但 
古 这 两 者 还 古 有 比较 大 的 差异 ， 对 象 池 着 重 在 对 象 的 复 用 上 ， 池 中 的 
每 个 对 象 古 可 替换 的 ， 从 同一 个 池 中 获得 A 对 象 和 B 对 和 象 对 客户 端 来 说 
古 完 全 相同 的 ， 它 主要 解决 复 用 ， 而 至 元 模式 在 主要 解决 的 对 象 的 共 
享 问题 ， 如 何 建 立 多 个 可 共享 的 细 粒 度 对 象 则 是 其 关注 的 重点 。 
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我 们 每 个 人 都 有 理想 ， 但 不 要 只 是 空想 ， 理 想 是 要 靠 今天 的 拼搏 
来 实现 的 。 今 天 咱们 就 来 谈 谈 自己 的 理想 ， 如 希望 成 为 一 个 富 贫 ， 身 
价 过 亿 ， 有 两 家 大 公司 ， 一 家 是 房地产 公司 ， 另 一 家 是 服装 制造 公 
司 。 这 两 家 公司 都 很 赚钱 ， 天 天 帮 你 累积 财富 。 其 实 你 并 不 关心 公司 
的 类 型 ， 你 关心 的 是 它们 是 不 是 在 赚钱 ， 赚 了 多 少 ， 这 才 是 你 关注 
的 。 商 人 嘛 ， 唯 利 是 图 是 其 本 性 ， 偷 税 漏税 是 方法 ， 欺 上 瞒 下 、 压 榨 
员工 血汗 是 利用 的 手段 ， 驳 用 类 图 表示 一 下 这 两 个 公司 ， 如 图 29-1 所 


修 ° 


+Vvold makeMoney() 
t+void producel() 
+void sell() 


图 29-1 鳃 利 模 式 的 类 图 


类 图 很 简单 ， 声 明了 一 个 Corp 抽 象 类 ， 定 义 一 个 公司 的 抽象 模 
型 ， 公 司 首 要 十 赚 线 的 ， 做 义务 或 善举 那 也 是 有 至 后 利 葵 文 撑 的 ， 还 
征 赞 成 这 句 话 “ 天 下 牛 熙 ， 儿 为 利 来 ， 天 下 所 所 ， 沸 为 利 往 ”。 我 们 先 
看 Corp 类 的 源 代码 ， 如 代码 清单 29-1 所 示 。 


代码 清单 29-1 抽象 公司 


public abstract class Corp { 
yn 


* 如 采 是 公司 就 应 该 有 生产 ， 不 管 是 软件 公司 还 是 制造 业 公司 
* 每 家 公司 生产 的 东西 都 不 一 样 ， 所 以 由 实现 类 来 完成 

4 

protected abstract void produce(); 


* 有 产品 了 ， 那 肯定 要 销售 啊 ， 不 销售 公司 怎么 生存 


*/ 
protected abstract void sell(); 


// 公 司 是 干什么 的 ? 赚钱 的 
public void makeMoney(){ 


以 


// 每 个 公司 都 是 一 样 ， 先 生产 
this.produce( ); 

// 然 后 销售 
this. sell( ); 


这 是 模板 方法 模式 啊 ? 是 的 ， 这 古 个 引 了 于 ， 请 继续 往 下 看 。 


适 的 方法 存在 合适 的 类 中 ， 这 个 基本 上 是 每 本 Java 基 础 书 上 都 会 讲 


的 ,但 
看 两 个 实 


苹 到 实际 的 项 目 中 应 用 的 时 候 就 不 是 这 么 回 事 儿 了。 我们 继续 


现 类 是 如 何 实现 的 ， 先 看 HouseCorp 类 ， 这 是 最 赚钱 的 公司 ， 


如 代码 请 单 29-2 所 示 。 


代码 清单 29-2 房地产 公司 


public class HouseCorp extends Corp { 


// 


房地产 公司 盖 房 


protected void produce() { 


} 
// 


System.out .println(" 房 地 产 公 司 盖 房 子 . . .") ) 


房地产 公司 卖房 子 ， 自 己 住 那 可 不 赚钱 


protected void sell() { 


了 
// 


System.out.println(" 房 地 产 公司 出 售 房 子 ..."); 
房地产 公司 很 High 了 ， 赚 钱 ， 计 算 利润 


public void makeMoney(){ 


super ,makeMoney( ); 
System.out.println(" 房 地 产 公司 赚 大 钱 了 ...")，; 


房地产 公司 按照 正规 翻译 来 说 应 该 是 realty corp， 这 个 是 比较 准确 


的 翻译 ， 


但 是 我 问 你 把 房地产 公司 翻译 成 英文 ， 你 的 第 一 反应 是 什 


么 ? house corp! 这 是 中 式 身 语 。 我 们 再 来 看 服 狼 公司， 虽然 不 景气 ， 
但 好 瓯 也 是 赚钱 的 ， 如 代码 清香 29-3 所 示 。 


代码 清单 29-3 服装 公司 


public class ClothesCorp extends Corp { 
// 服 装 公司 生产 的 就 是 衣服 了 
protected void produce() { 
System.out.println(" 服 装 公 司 生 产 衣服 ...")，; 


} 

// 服 装 公 司 卖 服装 ， 可 只 卖 服 装 ， 不 卖 穿 衣服 的 模特 

protected void sell() { 
System.out .println(" 服 装 公 司 出 售 衣 服 ,.."); 


} 

// 服 装 公 司 不 景气 ,但 怎么 说 也 是 赚钱 行业 

public void makeMoney(){ 
super ,makeMoney( ) ， 
System.out.printlLn(" 服 装 公司 赚 小 钱 . . .")， 


两 个 公司 部 有 了 ， 那 肯定 有 人 会 关心 两 个 公司 的 运营 情况 。 你 也 
要 知道 它 是 生产 什么 的 ， 以 及 赚 多 少 钱 吧 。 通 过 场景 类 来 进行 模拟 ， 
如 代码 清单 29-4 所 示 。 


代码 清单 29-4 场景 


public class Client { 
public static void main(String[] args) { 


System,out.println("------- 房地产 公司 是 这 样 运行 的 ------ 
-"); 

// 先 找到 我 的 公司 

HouseCorp houseCorp =new HouseCorp(); 

// 看 我 怎么 挣 钱 


houseCorp.makeMoney(); 
System.out.printlin("\n"); 
System.out.printin("------- 服装 公司 是 这 样 运行 的 - - - - - -- 


"); 


ClLothescorp clothesCorp = new ClothesCorp(); 
clothescorp.makeMoney( ); 


这 段 代 码 很 价 单 ， 运 行 结 末 如 下 所 示 : 


有 房地产 公司 是 这 样 运行 的 ------- 


房地产 公司 盖 房 子 ... 


房地产 公司 出 售 房 子 .… 


房地产 公司 赚 大 钱 了 .… 


i 服装 公司 是 这 样 运行 的 ------- 


服装 公司 生产 衣服 .… 
服装 公司 出 售 衣服 .… 


服装 公司 赚 人 小钱.… 


上 上述 代码 完全 可 以 揪 述 我 现在 的 公司 ,但 是 你 要 知道 万 物 痢 十 运 
动 的 ， 你 要 用 运动 的 眼光 看 问题 ， 公 司 才 会 发 展 .….. 终 于 有 一 天 你 宽 
得 赚钱 速度 太 慢 ， 于 是 你 上 下 足 通 ， 左 石 打 关 系 ， 终 于 开辟 了 一 条 赚 
钱 的 “ 康 庄 大 道 ”: 生产 山寨 产品 ! 什么 产品 呢 ? 即 市 场 上 什么 牌子 的 
东西 火爆 我 生产 什么 牌子 的 东西 ， 不 管 是 打火机 还 是 电脑 ， 只 要 它 火 
爆 ， 我 束 生 产 ， 赚 过 了 高 峰 期 束 换 个 产品 ， 打 一 枪 换 一 个 牌子 ， 不 承 
担 售 后 成 本 、 也 不 担心 销路 问题 ， 我 只 要 正品 的 十 分 之 一 的 价格 ， 你 
天 不 买 ? 哈哈 ， 赚 钱 啊 |! 


企业 的 方 回 定 下 来 了 ， 通 过 调查 ， 革 末 公 司 的 iPod 系列 产品 比较 火 
爆 ， 那 咱 驶 生产 这 个 ， 把 服装 广 改 成 iPod 生产 三 ， 看 类 图 的 变化 ， 如 图 


29-2 所 示 。 


Client 
+vold make Money() 
+void producel() 
+void sell() 


IPodCorp 


HouseCorp 


图 29-2 服 闭 公司 改头换面 后 的 类 图 


好 ， 我 的 企业 改头换面 了 ， 开 始 生产 iPod 产品 了 ， 看 我 IPodCorp 类 
的 实现 ， 如 代码 清单 29-5 所 示 。 


代码 清单 29-5 iPod 山寨 公司 


public class IPodCorp extends Corp { 
// 我 开始 生产 iPod ] 
protected void produce() { 
System.out .printlLn(" 我 生产 iPod. . ,")， 


3 
// 山 寨 的 jPod 很 畅销 ， 便 宜 嘛 


protected void sell() { 
System.out.println("iPod 畅 销 ,.."); 


} 

// 狂 赚钱 

public void makeMoney(){ 

super ,makeMoney( ); 

System.out .printlin(" 我 赚钱 呀 ...")， 


服 狠 工厂 改 成 了 电子 工厂 ， 你 这 个 董事 长 还 十 要 去 看 看 到 瓜 生 产 
什么 的 ， 场 景 类 如 代码 清单 29-6 所 示 。 


代码 清单 29-6 场景 


public class Client { 
public static void main(String[] args) { 
System.out.printin("------- 房地产 公司 是 按 这 样 运 行 的 - - - - 


// 先 找到 我 的 公司 

HouseCorp houseCorp =new HouseCorp(); 
// 看 我 怎么 挣 钱 

houseCorp.makeMoney(); 
System.out.println("\n"); 
System,out,println("------- 山寨 公司 是 按 这 样 


Se 


~ 


的 


ell 


-"); 
IPodCorp iPodcorp = new IPodCorp(); 
iPodCorp.makeMoney( ); 


确实 ， 只 用 修改 了 墨色 字体 这 儿 句 话 ， 服 妆 广 惑 开 始 变 成 山寨 iPod 
生产 车 间 ， 然 后 你 惑 看 着 你 的 财富 在 积累 。 山 寨 的 东西 不 需要 特别 的 
销售 渠道 正品 到 哪里 我 就 到 哪里 ，， 不 需要 维修 成 本 (大 不 了 给 你 
换个 ， 你 还 想 怎 么 样 ， 过 了 高 峰 期 我 就 改头换面 了 ， 你 找 谁 维修 去 ? 
投诉 ? 投诉 谁 呢 ?) ， 不 承担 广告 成 本 (正品 在 打 广 告 ， 我 还 需要 


吗 ? 需要 吗 ?) ， 但 是 也 有 犯愁 的 时 候 ， 这 是 一 个 山寨 工厂 ， 要 及 时 
地 生产 出 市 场 上 流行 的 产品 ， 转 型 要 快 ， 要 灵活 ,今天 从 生产 iPod 转 为 
生产 MP4, 明 天 再 转 为 生产 上 网 本 ， 这 都 需要 灵活 的 变化 ， 不 要 限制 得 
太 死 ! 那 问题 来 了 ， 每 次 我 的 厂房 ， 我 的 工人 ， 我 的 设备 都 在 ， 不 可 
能 每 次 我 换个 山寨 产品 广 子 就 彻底 不 要 了 “。 这 不 行 ， 成 本 起 高 了 点 ， 
那 怎么 办 ? 


Thinking,Thinking...I got an ideal ( 跳 跳 虎 语 ) ， 既 然 产品 和 工厂 绑 
得 太 死 ， 那 我 束 给 你 来 松 松 ， 改 变 设计 ， 如 图 29-3 所 示 。 


人 ~ Ss 人 ~ 


-Product product == = == 二 人 == 型 
+void beProducted() 


+Corp(Product product) +void beSelled() 
+void make Money() 


ShanZhaiCorp 


图 29-3 使 用 快速 变化 的 类 图 


公司 和 产品 之 间 建 立 关联 关系 ， 可 以 彻 抵 解决 以 后 山 窟 公司 生产 
产品 的 问题 ， 工 厂 想 换 产 品 ? 太 容 易 了 ! 看 程序 说 话 ， 先 看 Product 抽 
象 类 ， 如 代码 清单 29-7 所 示 。 


代码 清单 29-7 抽象 产品 类 


public abstract class Product { 
// 乔 管 是 什么 产品 它 总 要 能 被 生产 出 来 
public abstract void beProducted( ) ， 
// 生 产 出 来 的 东西 ， 一 定 要 销售 出 去 ， 否 则 亏本 
public abstract void beSelled!(); 


简单 ! 起 和 商 单 了 ! House 产 品类 如 代码 清单 29-8 所 示 。 


代码 清单 29-8 房子 


public class House extends Product { 
// 豆 奉 酒 就 豆腐 酒 呐 ， 好歹 也 是 房子 
public void beProducted() { 
System.out.println(" 生 产 出 的 房子 是 这 样 的 ..."); 


} 

// 虽 然 是 豆腐 酒 ， 也 是 能 够 销售 出 去 的 

public void beSelled() { 
System.out.println(" 生 产 出 的 房子 卖 出 去 了 ,.,."); 

} 


既然 古 产品 类 ， 那 肯定 有 了 两 种 行为 要 存在 :被 生产 和 被 销售 ， 否 
则 就 不 能 称 为 产品 了 。 我 们 再 来 看 iPod 产 品类 ， 如 代码 清单 29-9 所 示 。 


代码 清单 29-9 iPod 产品 


public class IPod extends Product { 
public void beProducted() { 
System.out.println(" 生 产 出 的 jPod 是 这 样 的 ..."); 
} 


public void beSelled() { 
System.out.println(" 生 产 出 的 jPod 卖 出 去 了 ...")， 
} 


产品 是 由 公司 生产 出 来 的 ， 我 们 来 看 公司 Corp 抽 象 类 ， 如 代码 清 
单 29-10 所 示 。 


代码 清单 29-10 抽象 公司 类 


public abstract class Corp { 
// 定 义 一 个 抽象 的 产品 对 象 ， 不 知道 具体 是 什么 产品 
private Product product ; 
// 构 造 画 数 ， 由 子 类 定义 传递 具体 的 产品 进来 
public Corp(Product product ){ 
this.product = product,; 


} 

// 公 司 是 干什么 的 ? 赚钱 的 ! 

public void makeMoney(){ 
// 每 家 公司 都 是 一 样 ， 先 生产 
this.product.beproducted( ); 
// 然 后 销售 
this.product.beSelled!( ); 


这 里 多 了 个 有 参 构造 ， 其 目的 是 要 继承 的 子 类 都 必 选 重 写 目 己 的 
有 参 构 造 男 数 ， 把 产品 类 传递 进来 ， 再 看 子 类 HouseCorp 的 实现 ， 如 代 
码 清 单 29-11 所 示 。 


代码 清单 29-11 房地产 公司 


public class HouseCorp extends Corp { 
// 定 义 传递 一 个 House 产 品 进 来 
public HouseCorp(House house)t{ 
super (house); 
} 


// 房 地 产 公司 很 High 了， 赚钱 ， 计 算 利润 
public void makeMoney(){ 
super ,makeMoney( ); 
System.out.println(" 房 地 产 公司 赚 大 钱 了 ...")，; 


理解 上 没有 多 少 难度 ， 不 多 说 ， 继 续 看 山寨 公司 的 实现 ， 如 代码 
清单 29-12 所 示 。 


代码 清单 29-12 山寨 公司 


public class ShanzhaiCorp extends Corp { 

// 产 什么 产品 ， 不 知道 ， 等 被 调用 的 才 知 道 

public ShanzhaiCorp(Product product)t 
super (product ); 


} 

// 狂 赚钱 

public void makeMoney(){ 

super ,makeMoney( ) ， 

System,.out .printlin(" 我 赚钱 呀 ...")， 


HouseCorp 类 和 ShanZhaiCorp 类 的 区 别 是 在 有 参 构造 的 参数 类 型 
上 ，HouseCorp 类 比较 明确 ， 我 就 是 只 要 House 类 ， 所 以 直接 定义 传递 
进来 的 必须 是 House 类 ， 一 个 类 尽 可 能 少 地 承担 职责 ， 那 方法 也 一 样 ， 
既然 HouseCorp 类 已 经 非常 明确 地 只 生产 House 产 品 ， 那 为 什么 不 定义 
成 House 类 型 呢 ? ShanZhaiCorp 束 不 同 了 ， 它 确定 不 了 生产 什么 类 型 。 


好 了 ， 两 大 对 应 的 阵营 都 已 经 产生 了 。 我 们 再 看 Client 程 序 ， 如 代 
码 清单 29-13 所 示 。 


代码 清单 29-13 场景 类 


public class Client { 
public static void main(String[] args) { 
House house = new House(); 


System.out.printin("------- 房地产 公司 是 这 样 运行 的 - - - - -- 
-"); 

// 先 找到 房地产 公司 

HouseCorp houseCorp =new HouseCorp(house); 

// 看 我 怎么 挣 钱 


houseCorp.makeMoney(); 
System.out.println("\n"); 
// 山 寨 公 司 生产 的 产品 很 多 ， 不 过 我 只 要 指定 产品 就 成 了 


System.out.println("------- 山寨 公司 是 这 样 运 行 的 - ------ 
"); 


IPod() ) ; 


ShanZzhaiCcorp shanzhaiCorp = new ShanzhaiCorp(new 


shanzhaiCorp.makeMoney( ) ， 


证 


行 结果 如 下 所 示 : 


i 


2 房地产 公司 是 这 样 运行 的 ------ 


产 出 的 房子 是 这 样 的 … 


产 出 的 房子 卖 出 去 了 .… 


ee 山寨 公司 是 这 样 运行 的 ------- 


生产 出 的 iPod 是 这 个 样子 的 .… 


生 严 出 的 iPod 卖 出 去 了 ... 


我 赚钱 呀 .… 


突然 有 一 天 ， 老 板 民心 发 现 了 ， 不 准备 生产 这 种 “三 无 "产品 了 ， 
那 我 们 程序 该 怎么 修改 呢 ? 如 果 仍 重 操 昌 业 ， 生 产 衣 服 ， 那 该 如 何 处 
理 呢 ? 很 容易 处 理 ， 增 加 一 个 产品 类 ， 然 后 稍稍 修改 一 下 场景 束 可 以 
了 ， 我 们 来 看 衣服 产品 类 ， 如 代码 清单 29-14 所 示 。 


代码 清单 29-14 服装 


public class Clothes extends Product { 
public void beProducted() { 
System.out.println(" 生 产 出 的 衣服 是 这 样 的 ..."); 


public void beSelled() { 


He 


System.out.println(" 生 产 出 的 衣服 3 


然后 再 稍稍 修改 一 下 场景 类 ， 如 代码 清单 29-15 所 示 。 


代码 清单 29-15 场景 类 


public class Client { 
public static void main(String[] args) { 
House house = new House(); 


System.out.printin("------- 房地产 公司 是 这 样 运行 的 - - - --- 
-"); 

// 先 找到 房地产 公司 

HouseCorp houseCorp =new HouseCorp(house); 

// 看 我 怎么 挣 钱 


houseCorp.makeMoney(); 

System.out.println("\n"); 

// 山 寨 公 司 生产 的 产品 很 多 ， 不 过 我 只 要 指定 产品 就 成 了 
System,out,println("------- 山寨 公司 是 这 样 运行 的 ------- 


"); 
Clothes()); 


} 


ShanZzhaiCcorp shanzhaiCorp = new ShanzhaiCorp(new 


shanzhaiCorp.makeMoney( ); 


修改 后 的 运行 结果 如 下 所 示 : 


ee 房地产 公司 是 这 样 运行 的 ------- 


生产 出 的 房子 是 这 样 的 … 
生 


生产 出 的 衣服 是 这 样 的 .… 


生产 出 的 衣服 卖 出 去 了 .… 


我 赚钱 呀 .… 


看 代码 中 的 黑体 部 分 ， 就 修改 了 这 一 条 语句 吕 完 成 了 生产 产品 的 
转换 。 那 我 们 深入 思考 一 下 ， 既 然 万 物 都 是 运动 的 ， 我 现在 只 有 房 地 
产 公 司 和 山寨 公 司 ， 那 以 后 我 会 不 会 增加 一 些 其 他 的 公司 呢 ? 或 者 房 
地 产 公司 会 不 会 对 业务 进行 细 化 ， 如 分 为 公寓 房 公 司 、 别 墅 公司 ， 以 
及 商业 房 公司 等 呢 ? 那 我 告诉 你 ,会 的 ! 绝对 会 的 ! 但 是 你 发 沉没 
有 ， 这 种 变化 对 我 们 上 面 的 类 图 来 说 不 会 做 大 的 修改 ， 充 其 量 只 是 扩 
展 : 


e 增加 公司 ， 要 么 继承 Corp 类 ， 要 么 继承 HouseCorp 或 
ShanZhaiCorp ， 不 用 再 修改 原 有 的 类 了 。 


e 增加 产品 ， 继 承 Product 类 ， 或 者 继承 House 类 ， 你 要 把 房子 分 为 
公寓 房 、 别 墅 、 商 业 用 房 等 。 


你 唯一 要 修改 的 就 是 Client 类 。 类 都 增加 了 ， 高 层 模 块 也 需要 修 
改 ， 也 了 束 是 说 Corp 类 和 Product 类 都 可 以 目 由 地 扩展 ， 而 不 会 对 整个 应 
用 产生 太 大 的 变更 ， 这 束 是 桥 桨 模式 。 


29.2 桥梁 模式 的 定义 


桥梁 模式 (Bridge Pattern) 也 叫做 桥接 模式 ， 是 一 个 比较 简单 的 模 
式 ， 其 定义 如 下 : Decouple an abstraction from its implementation so that 
the two can vary independently. 《将 抽象 和 实现 解 奈 ， 使 得 两 者 可 以 独立 
地 变化 。) 


桥架 模式 的 重点 是 在 “ 解 稍 "上 ， 如 何 让 它们 两 兰 解 耦 羡 我 们 要 了 
解 的 重点 ， 我 们 先 来 看 桥梁 模式 的 通用 类 ， 如 图 29-4 所 示 。 


Abstraction 


Implementor 
= 和 = 
+OperationImp() 


+Operation( ) 


ConcreteImplementor 


RefinedAbstraction 
| 
| | 


图 29-4 桥梁 模式 通用 类 图 


我 们 先 来 看 桥梁 模式 中 的 4 个 角色 。 


抽象 化 角色 


@ Abstraction 


它 的 主要 职责 是 定义 出 该 角色 的 行为 ， 同 时 保存 一 个 对 实现 化 角 
色 的 引用 ， 该 角色 一 般 是 抽象 类 。 


实现 化 角色 


e [Implementor 


它 是 接口 或 者 抽象 类 ， 定 义 角 色 必 需 的 行为 和 属性 。 


修正 抽象 化 角色 


e RefinedAbstraction 


它 引用 实现 化 角色 对 抽象 化 角色 进行 修正 。 


具体 实现 化 角色 


e@ ConcreteImplementor 


它 实 现 接口 或 抽象 类 定义 的 方法 和 属性 。 


桥架 模式 中 的 几 个 名 词 比较 擂 口 ， 大 家 只 要 记 住 一 句 话 就 成 : 抽 
象 角色 引用 实现 角色 ， 或 者 说 抽象 角色 的 部 分 实现 是 由 实现 角色 完成 
的 。 我 们 来 看 其 通用 源码 ， 先 看 实现 化 角色 ， 如 代码 清单 29-16 所 示 。 


代码 清单 29-16 实现 化 角色 


public interface Implementor { 
// 基 本 方 ? 
public void doSomething( ); 
public void doAnything() ; 


它 没 有 任何 特殊 的 地 方 ， 就 是 一 个 一 般 的 接口 ， 定 义 要 实现 的 方 
法 。 其 实现 类 如 代码 清单 29-17 所 示 。 


代码 清单 29-17 具体 实现 化 角色 


public class ConcreteImplementor1 implements Implementor{ 
public void doSomething(){ 
// 业 务 逻 辑 处 理 


} 

public void doAnything(){ 
// 业 务 逻 辑 处 理 

} 


public class ConcreteImplementor2 implements Implementor{ 
public void doSomething(){ 
// 业 务 逻 辑 人 处理 


} 

public void doAnything(){ 
// 业 务 逻 辑 处 理 

} 


上 上 面 定 义 了 两 个 具体 实现 化 角色 一 一 代表 两 个 不 同 的 业务 逻辑 。 
我 们 再 来 看 抽象 化 角色 ， 如 代码 清单 29-18 所 示 。 


代码 清单 29-18 抽象 化 角色 


public abstract class Abstraction { 
// 定 义 对 实现 化 角色 的 引用 
private Implementor imp; 
// 约 束 子 类 必须 实现 该 构造 函数 
public Abstraction(Implementor _imp)t{ 
this.imp = _imp; 
} 


// 自 身 的 行为 和 属性 
public void request(){ 
this.imp.doSsomething(); 


} 
// 获 得 实现 化 角色 
public Implementor getImp(){ 


return imp; 


各 位 可 能 要 问 ， 为 什么 要 增加 一 个 构造 画 数 ? 符 案 是 为 了 提醒 子 
类 ， 你 必须 做 这 项 工作 ， 指 定 实现 者 ， 特 别 是 已 经 明确 了 实现 者 ， 则 
尽量 清晰 明确 地 定义 出 来 。 我 们 来 看 具体 的 抽象 化 角色 ， 如 代码 清单 
29-19 所 示 。 


代码 清单 29-19 具体 抽象 化 角色 


public class RefinedAbstraction extends Abstraction { 
// 窗 写 构 造 画 数 
public RefinedAbstraction(Implementor _imp)t{ 
super (_imp); 


bl; 

// 修 正 父 类 的 行为 

@Override 

public void request(){ 
DA 


* 业务 处 理 ,. ， 
*/ 


super .request(); 
super .getIimp().doAnything( ); 


想 想 看 ， 如 采 我 们 的 实现 化 角色 有 很 多 的 子 接口 ， 然 后 是 一 堆 的 
子 实现 。 如 琳 在 构造 钞 数 中 不 传递 一 个 尽量 明确 的 实现 着 ， 代 码 束 很 
不 清晰 。 我 们 来 看 场景 类 如 何 模拟 ， 如 代码 清单 29-20 所 示 。 


代码 清单 29-20 场景 


public class Client { 
public static void main(String[] args) { 
// 定 义 一 个 实现 化 角色 


Implementor imp = new ConcreteImplementor1(); 
// 定 义 一 个 抽象 化 角色 

Abstraction abs = 

// 执 行 行文 

abs,redquest() ， 


new RefinedAbstraction(imp); 


桥梁 模式 是 一 个 非常 简单 的 模式 ， 它 只 是 使 用 类 间 的 聚合 ; 
系 、 继 承 、 覆 写 等 常用 功能 ， 但 是 它 却 提供 了 一 个 非常 清晰 、 稳 定 的 
架构 。 


29.3 桥梁 模式 的 应 用 
29.3.1 桥梁 模式 的 优点 


e 抽象 和 实现 分 离 

这 也 是 桥梁 模式 的 主要 特点 ， 它 完全 是 为 了 解决 继承 的 缺点 而 提 
出 的 设计 模式 。 在 该 模式 下 ， 实 现 可 以 不 受 抽 和 象 的 约束 ， 不 用 再 绑 定 
在 一 个 固定 的 抽象 层次 上 。 


e 优秀 的 扩充 能 


看 看 我 们 的 例子 ， 想 增加 实现 ? 没 问 题 ! 想 增加 抽象 ， 也 没有 问 
题 ! 只 要 对 外 骏 露 的 接口 层 允 许 这 样 的 变化 ， 我 们 已 经 把 变化 的 可 能 
性 减 到 最 小 。 

e 实现 细 世 对 客户 透明 

客户 不 用 关心 细 万 的 实现 ， 它 已 经 由 抽象 层 通 过 聚合 关系 完成 了 


封装 。 


29.3.2 桥架 模式 的 使 用 场景 


e 不 布 望 或 不 适用 使 用 继承 的 场景 


例如 继承 层次 过 渡 、 无 法 更 细 化 设计 颗粒 等 场景 ， 需 要 考虑 使 用 
桥架 模式 。 


e 接口 或 抽象 类 不 稳定 的 场景 


明知 道 接口 不 稳定 还 想 通 过 实现 或 继承 来 实现 业务 需求 ， 那 是 得 
不 偿 失 的 ， 也 是 比较 失败 的 做 法 。 


e 重用 性 要 求 较 融 的 场景 


设计 的 颗粒 度 越 细 ， 则 被 重用 的 可 能 性 就 越 大 ， 而 采用 继承 则 受 
父 类 的 限制 ， 不 可 能 出 现 太 细 的 颗粒 度 。 


29.3.3 桥梁 模式 的 注意 事项 


桥架 模式 是 非常 简单 的 ， 使 用 该 模式 时 主要 考虑 如 何 拆 分 抽象 和 
实现 ， 并 不 是 一 涉及 继承 吏 要 考虑 使 用 该 模式 ， 那 还 要 继承 干什么 
呢 ? 桥架 模式 的 意图 还 是 对 变化 的 封装 ， 尽 量 把 可 能 变化 的 因 系 封闭 
到 最 细 、 最 小 的 逻辑 单元 中 ， 避 免 风险 扩散 。 因 此 读者 在 进行 系统 设 
计时 ， 发 现 类 的 继承 有 N 层 时 ， 可 以 考虑 使 用 桥梁 模式 。 


29.4 最 佳 实践 


大 家 对 类 的 继承 有 什么 看 法 吗 ? 继承 的 优点 有 很 多 ， 可 以 把 公共 
的 方法 或 属性 抽取 ， 父 类 封闭 共性 ， 子 类 实现 特性 ， 这 是 继承 的 基本 
功能 。 缺 点 有 没有 ? 有 ! 即 强 侵 入 ， 父 类 有 一 个 方法 ， 子 类 也 必须 有 
这 个 方法 。 这 有 是 不 可 选择 的 ， 会 市 来 扩展 性 的 问题 。 我 举 个 简单 的 例 
子 来 说 明 : Father 类 有 一 个 方法 A，Son 继 承 了 这 个 方法 ， 然 后 
GrandSon 也 继承 了 这 个 方法 ， 问 题 是 突然 有 一 天 Son 要 重 写 父 类 的 这 
个 方法 ， 他 敢 做 吗 ? 绝对 不 敢 ! GrandSon 要 用 从 Father 继 承 过 来 的 方 
法 A， 如 果 你 修改 了 ， 那 就 要 修改 Son 和 GrandSon 之 间 的 关系 ， 那 这 个 
风险 束 太 大 了 ! 


这 里 讲 的 这 个 桥架 模式 惑 是 这 一 问题 的 解决 方法 ， 桥 架 模 式 描 述 
了 类 间 弱 关联 关系 ， 还 说 上 面 的 那个 例子 ，Father 类 完全 可 以 把 可 能 
会 变化 的 方法 放出 去 ，Son 于 类 要 拥有 这 个 方法 很 简单 ， 桥 梁 搭 过 
去 ， 获 得 这 个 方法 ，GrandSon 也 一 样 ， 即 使 你 Son 子 类 不 想 使 用 这 个 
方法 也 没关系 ， 对 GrandSon 不 产生 影响 ， 它 不 是 从 Son 中 继承 来 的 方 
| 


不 能 说 继承 不 好 ， 它 非常 好 ， 但 是 有 缺点 ， 我 们 可 以 扬长 避 短 ， 
对 于 比较 明确 不 发 生变 化 的 ， 则 通过 继承 来 完成 ， 大 不 能 确定 征 否 会 


发 生变 化 的 ， 那 束 认 为 是 会 发 生变 化 ， 则 通过 桥梁 模式 来 解决 ， 这 才 
古 一 个 完美 的 世界 。 


第 30 章 
第 31 章 
第 32 章 


第 33 章 


第 三 部 分 “ 谁 的 地 盘 谁 做 主 
一 一 设计 模式 PK 
创建 类 模式 大 PK 
结构 类 模式 大 PK 
行为 类 模式 大 PK 
跨 战区 PK 


第 30 章 ”创建 类 模式 大 PK 


创建 类 模式 包括 工厂 方法 模式 、 建 造 者 模式 、 抽 象 工厂 模式 、 单 
例 模式 和 原型 模式 ， 它 们 都 能 够 提供 对 象 的 创建 和 管理 职责 。 其 中 的 
单 例 模 式 和 原型 模式 非常 容易 理解 ， 单 例 模 式 是 要 保持 在 内 存 中 只 
一 个 对 象 ， 原 型 模式 是 要 求 通过 复制 的 方式 产生 一 个 新 的 对 象 ， 这 两 
个 不 容易 混淆 。 剩 下 的 束 是 工厂 方法 模式 、 抽 和 象 工厂 模式 和 建造 者 模 
式 了 ， 这 三 个 之 间 有 较 多 的 相似 性 。 


30.1 工厂 方法 模式 VS 建造 者 模式 


工厂 方法 模式 注重 的 是 整体 对 象 的 创建 方法 ， 而 建造 者 模式 注重 
的 是 部 件 构建 的 过 程 ， 旨 在 通过 一 步 一 步 地 精确 构造 创建 出 一 个 复杂 
的 对 象 。 我 们 举 个 简单 例子 来 说 明 两 者 的 差异 ， 如 要 制造 一 个 超人 ， 
如 果 使 用 工厂 方法 模式 ， 直 接 产 生出 来 的 就 是 一 个 力 大 无 穷 、 能 够 飞 
翔 、 内 链 外 罕 的 超人 ; 而 如 有 果 使 用 建造 者 模式 ， 则 需要 组 装 手 、 头 、 
脚 、 红 干 等 部 分 ， 然 后 再 把 内 裤 外 罕 ， 于 古 一 个 超人 束 放 生 了 。 纯 粹 
使 用 文字 来 描述 比较 枯燥 ， 我 们 还 是 通过 程序 来 更 加 清晰 地 认识 两 者 
的 兰 别 。 


30.1.1 按 工 三 方法 建造 超人 


首先 ， 按 照 工厂 方法 模式 创建 出 一 个 超人 ， 类 图 如 图 30-1 所 示 。 


Client 


SuperManFactory 
| 


+ISuperMan createSuperMan(Strng type) 


<<interface>> 
ISuperMan 
Es 
+vold specialTalent() 


AdultSuperMan ChildSuperMan 
Te = 
| | [| 


图 30-1 按 工厂 方法 建造 超人 


类 图 中 我 们 按照 年 龄 段 把 超人 分 为 两 种 类 型 : 成 年 超人 (如 克拉 
克 、 超 能 先生 ) 和 未 成 年 超人 (如 Dash、Jack) 。 这 是 一 个 非常 正宗 的 
工厂 方法 模式 ， 定 义 一 个 产品 的 接口 ， 然 后 再 定义 两 个 实现 ， 通 过 超 
人 制造 工厂 制造 超人 。 想 想 看 我 们 对 超人 最 大 印象 是 什么 ?当然 是 他 
的 超 能 力 ， 我 们 以 specialTalent (特殊 天 赋 ) 方法 来 代表 ， 先 看 抽象 产 
品类 ， 如 代码 清单 30-1 所 示 。 


代码 清单 30-1 超人 接口 


public interface ISuperMan { 
// 每 个 超人 都 有 特殊 技能 


public void specialTalent( ) ; 


产品 的 接口 定义 好 了 ， 我 们 再 来 看 具体 的 产品 。 侈 看 成 年 超人 ， 
很 简单 ， 如 代码 清单 30-2 所 示 。 


代码 清单 30-2 成 年 超人 


public class AdultSuperMan Implements ISuperMan { 
// 超 能 先生 

public void specialTalent() { 
System,out ,println(" 超 人 力 大 无 穷 ") ; 


未 成 年 超人 的 代码 如 代码 清单 30-3 所 示 。 


代码 清单 30-3 未 成 年 超人 


public class ChildSuperMan implements ISuperMan { 
// 超 能 先生 的 三 个 孩子 
public void specialTalent() { 
System.out.printlin(" 小 超人 的 能 力 是 刀枪 不 入 、 快 速 运 动 " ) ; 


产品 都 具备 ， 那 我 们 编写 一 个 工 三 类， 其 意图 就 是 生产 超人 ， 具 
体 电 成 年 超人 还 是 来 成 年 超人 ， 则 由 客户 端 决 定 ， 如 代码 清单 30-4 所 


修 ° 


代码 清单 30-4 超人 制造 工厂 


public class SuperManFactory { 
// 定 义 一 个 生产 超人 的 工厂 


public static ISuperMan createSuperMan(String type)t{ 
// 根 据 输入 参数 产生 不 同 的 超人 
if(type.equalsIgnoreCase("adult"))t{ 
// 生 产 成 人 超人 
return new AdultSuperMan( ) ; 
}else if(type.equalsIgnoreCase("child"))t 
// 生 产 未 成 年 超人 


return new ChildSuperMan( ) ， 


}elsef 
} 


return null; 


产品 有 了 ， 工 三 类 也 有 了 ， 剩 下 的 工作 殉 是 开始 生产 超人 。 这 也 
非常 简单 ， 如 代码 清单 30-5 所 示 。 


代码 清单 30-5 场景 


public class Client { 
// 模 拟 生 产 超人 
public static void main(String[] args) { 
// 生 产 一 个 成 年 超人 
ISuperMan adultSuperMan = 
SuperManFactory.createSuperMan("adult"); 
// 展 示 一 下 超人 的 技能 
adultSuperMan.specialTalent(); 


建 并 了 一 个 超人 生产 工厂 ， 年 复 一 年 地 生产 超人 ， 对 于 具体 生产 
出 的 产品 ， 不 管 是 成 年 超人 还 是 未 成 年 起 人 ， 都 是 一 个 模样 : 深 监 
紧身 衣 、 胸 前 $ 标 记 、 内 裤 外 穿 ， 没 有 特殊 的 地 方 。 但 是 我 们 的 目的 达 
到 了 一 一 生产 出 超人 ， 托 救 全 人 类 ， 这 束 是 我 们 的 意图 。 具 体 怎么 生 
产 、 怎 么 组 骤 ， 这 不 是 工 上 方法 模式 要 考虑 的 ， 也 天 是 说 ， 工 厂 模 式 
关注 的 是 一 个 产品 整体 ， 生 产 出 的 产品 应 该 具有 相似 的 功能 和 架构 。 


通过 工矿 方法 模式 生产 出 对 象 ， 然 后 由 客户 端 进行 对 象 的 


注意 
但 是 并 不 代表 所 有 生产 出 的 对 象 都 必须 具有 相同 的 状态 和 


其 他 操作 ， 
行为 ， 它 是 由 产品 所 决定 。 


30.1.2 按 建 造 者 模式 建造 超人 


我 们 再 来 看 看 建造 者 模式 是 如 何 生 产 超人 的 ,如 图 30-2 所 示 。 


#SuperMan superMan -String body 


+void setBody(String body) -String specialTalent 

+SuperMan getA dultSuperMan() +void setSpecialTalent(String st) 

+SuperMan getChildSuperMan() +void setSpecialSymbol(String ss) 
+SuperMan getSuperMan() 


-Builder adultBuilder 
-Builder childBuilder 


-String specialSymbol 


+getter/setter() 


AdultSuperManBuilder ChildSuperManBuilder 
st 


图 30-2 按 建造 者 模式 生产 超人 


又 是 一 个 典型 的 建造 者 模式 ! 哎 ， 不 对 呀 ! 通用 模式 上 抽象 建造 
者 与 产品 类 没有 关系 呀 ! 是 的 ， 我 们 当然 可 以 加 强 了 ， 我 们 在 抽象 建 
造 者 上 使 用 了 模板 方法 模式 ， 每 一 个 建造 者 都 必须 返回 一 个 产品 ， 但 
征 产 品 是 如 何 制造 的 ， 则 由 各 个 建造 者 自己 负责 。 我 们 来 看 看 程序 ， 


先 看 产品 类 ， 如 代码 请 单 30-6 所 示 。 


代码 清单 30-6 超人 产品 


public class SuperMan { 

// 超 人 的 颈 体 

private String body; 

// 超 人 的 特殊 技能 

private String SpecialTalent 

// 超 人 的 标志 

private String specialSymbol; 

public String getBody() { 
return body; 


public void setBody(String body) { 
this,body = body; 


} 
public String getSpecialTalent() { 
return specialTalent; 


public void setSpecialTalent(String specialTalent) { 
this.specialTalent = specialTalent; 


} 
public String getSpecialSymbol() { 
return specialSymbol; 


} 

public void setSpecialSymbol(String specialSymbol) { 
this.specialSymbol = specialSymbol; 

} 


超人 这 个 产品 是 由 三 部 分 组 成 : 躯体 、 特 殊 技能、 身份 标记 ， 这 
就 类 似 于 电子 产品 ， 首 先生 产 出 一 个 固件 ， 然 后 再 安装 一 个 灵魂 ( 软 
件 驱 动 ) ， 最 后 再 打上 产品 标签 。 完 事 了 ! 一 个 菜 新 的 产品 就 诞生 
了 ! 我 们 的 超人 也 是 这 样 生产 的 ， 先 生产 一 个 普通 的 躯体 ， 然 后 注入 
特殊 技能 ， 最 后 打上 S 标 签 ， 一 个 超人 生产 完毕 。 我 们 再 来 看 一 下 建造 
者 的 抽象 定义 ， 如 代码 清单 30-7 所 示 。 


代码 清单 30-7 抽象 建造 者 


public abstract class Builder 1{ 
// 定 义 一 个 超人 的 应 用 
protected final SuperMan superMan = new SuperMan(); 
// 构 建 出 超人 的 颈 体 
public void setBody(String body)t{ 
this. superMan.setBody(body); 


} 

// 构 建 出 超人 的 特殊 技能 

public void setSpecialTalent(String st)t{ 
this.superMan.setSpecialTalent(st); 


} 

// 构 建 出 超人 的 特殊 标记 

public void setSpecialSymbol(String ss)t{ 
this. superMan.setSpecialSymbol(ss); 


} 
// 构 建 出 一 个 完整 的 超人 
public abstract SuperMan getSuperMan( ) ， 


一 个 典型 的 模板 方法 模式 ， 超 人 的 各 个 部 件 〈 颈 体 、 有 灵魂 、 标 
志 ) 都 准备 好 了 ， 上 有 具体 怎么 组 装 则 是 由 实现 类 来 决定 。 我 们 移 来 看 成 
年 超人， 如 代码 清单 30-8 所 示 。 


代码 清单 30-8 成 年 超人 建造 者 


public class AdultSuperManBuilder extends Builder 1{ 
Q@Override 
public SuperMan getSuperMan() { 
super ,setBody(" 强 壮 的 躯体 " ) ， 
super .setSpecialTalent(" 会 飞行 ") ; 
super .setSpecialSymbol(" 胸 前 带 S 标 记 " ) ， 
return Super. SuperMan 


皇 么 回 事 ? 在 第 11 章 中 讲解 建造 者 模式 的 时 候 在 产品 中 使 用 了 模 
板 方法 模式 ， 在 这 里 怎么 把 模板 方法 模式 迁移 到 建造 者 了 ? 怎么 会 这 
样 ? 你 是 不 是 在 发 出 这 样 的 疑问 ? 别 疑 四 了 ! 设计 模式 只 是 提供 了 一 


个 解决 问题 的 意图 : 复杂 对 象 的 构建 与 它 的 表示 分 离 ， 而 没有 具体 定 
出 一 个 设计 模式 必须 是 这 样 的 实现 ， 必 须 是 这 样 的 代码 ， 灵 活 运 用 模 
式 才 是 其 根本 ， 别 学 死板 了 。 


我 们 继续 看 未 成 年 超人 的 建造 者 ， 如 代码 清单 30-9 所 示 。 


代码 清单 30-9 未 成 年 超人 建造 者 


public class ChildSuperManBuilder extends Builder { 
@Override 
public SuperMan getSuperMan() { 
super ,setBody(" 强 壮 的 躯体 " ) ， 
super .setSpeclialTalent(" 刀 枪 不 入 ") ， 
super ,setSpecialSymbol(" 胸 前 带 小 S 标 记 " ) ， 
return Super. SuperMan ， 


大 家 注意 看 我 们 这 两 个 具体 的 建造 者 ， 它 们 都 关注 了 产品 的 各 个 
部 分 ， 在 某 些 应 用 场景 下 甚至 会 关心 产品 的 构建 顺序 ， 即 使 是 相同 的 
部 件 ， 装 配 顺序 不 同 ， 产 生 的 结果 也 不 同 ， 这 也 正 是 建造 者 模式 的 意 
图 : 通过 不 同 的 部 件 、 不 同 装 配 产生 不 同 的 复杂 对 象 。 我 们 再 来 看 导 
沉 类 ， 如 代码 清单 30-10 所 示 。 


代码 清单 30-10 导演 类 


public class Director { 

// 两 个 建造 者 的 应 用 

private static Builder adultBuilder = new 
AdultSuperManBuilder(); 

// 未 成 年 超人 的 建造 者 

private static Builder childBuilder = new 
childSuperManBuilder(); 

// 建 造 一 个 成 年 、 会 飞行 的 超人 


public static SuperMan getAdulLtSuperMan( ){ 
return adultBuilder.getSuperMan() ; 
} 


// 建 造 一 个 未 成 年 、 刀 枪 不 入 的 超人 

public static SuperMan getChildSuperMan(){ 
return childBuilder .getSuperMan(); 

} 


这 很 简单 ， 不 多 说 了 ! 看 看 场景 类 是 如 何 调 用 的 ， 如 代码 清单 30- 
11 所 示 。 


代码 清单 30-11 场景 


public class Client { 
public static void main(String[] args) { 
// 建 造 一 个 成 年 超人 
SuperMan adultSuperMan = 
Director.getAdultSuperMan( ) ; 
// 展 示 一 下 超人 的 信息 
adultSuperMan.getSpecialTalent(); 


这 个 场景 类 的 写法 与 工厂 方法 模式 是 相同 的 ， 但 是 你 可 以 看 到 ， 
在 建立 超人 的 过 程 中 ， 建 造 者 必须 关注 超人 的 各 个 部 件 ， 而 工厂 方法 
模式 则 只 关注 超人 的 整体 ， 这 就 是 两 着 的 区 别 。 


30.1.3 最 佳 实践 


工厂 方法 模式 和 建造 者 模式 都 属于 对 象 创建 类 模式 ， 都 用 来 创建 
类 的 对 象 。 但 它们 之 间 的 区 别 还 是 比较 明显 的 。 


。 意图 不 同 


在 工厂 方法 模式 里 ， 我 们 关注 的 十 一 个 产品 整体 ， 如 超人 整体 ， 
无 须 关 心 产 品 的 各 部 分 是 如 何 创 建 出 来 的 ， 但 在 建造 者 模式 中 ， 一 个 
具体 产品 的 产生 是 依赖 各 个 部 件 的 产生 以 及 装配 顺序 ， 它 关注 的 是 “由 
零件 一 步 一 步 地 组 装 出 产品 对 象 *。 简单 地 说 ， 工 厂 模 式 是 一 个 对 象 创 
建 的 粗 线 条 应 用 ， 建 造 者 模式 则 是 通过 细 线 条 勾勒 出 一 个 复杂 对 象 ， 
关注 的 是 产品 组 成 部 分 的 创建 过 程 。 


e 产品 的 复杂 度 不 同 


工 三 方法 模式 创建 的 产品 一 般 都 是 单一 性 质 产 品 ， 如 成 年 超人 ， 
都 是 一 个 模样 ， 而 建造 者 模式 创建 的 则 是 一 个 复合 产品 ， 它 由 各 个 间 
件 复 合 而 成 ， 部 件 不 同 产品 对 象 当 然 不 同 。 这 不 是 说 工厂 方 法 模式 创 
建 的 对 象 简 单 ， 而 是 指 它们 的 粒度 大 小 不 同 。 一 般 来 说 ， 工 三 方法 模 
式 的 对 象 粒度 比较 粗 ， 建 造 者 模式 的 产品 对 象 粒 度 比较 细 。 


两 者 的 区 别 有 了 ， 那 在 具体 的 应 用 中 ， 我 们 该 如 何 选 择 呢 ? 是 用 
工矿 方法 模式 来 创建 对 象 ， 还 是 用 建造 者 模式 来 创建 对 象 ， 这 完全 取 
决 于 我 们 在 做 系统 设计 时 的 意图 ， 如 果 需 要 详细 关注 一 个 产品 部 件 的 
生产 、 安 装 步 又 ， 则 选择 建造 者 ， 否 则 选择 工厂 方法 模式 。 


30.2 抽象 工厂 模式 VS 建 近 痢 模 式 


抽象 工厂 模式 实现 对 产品 家 族 的 创建 ， 一 个 产品 家 族 是 这 样 的 一 
系列 产品 : 具有 不 同 分 类 维度 的 产品 组 合 ， 采 用 抽象 工厂 模式 则 是 不 
需要 关心 构建 过 程 ， 只 关心 什么 产品 由 什么 工厂 生产 即 可 。 而 建造 者 
模式 则 是 要 求 按照 指定 的 蓝图 建造 产品 ， 它 的 主要 目的 是 通过 组 装 零 
配件 而 产生 一 个 者 产品， 两 者 的 区 别 还 是 比较 明显 的 ， 但 是 还 有 读者 
对 这 两 个 模式 产生 混 清 ， 我 们 通过 一 个 例子 说明 两 者 的 过细 


演 


现代 化 的 汽车 工厂 能 够 批量 生产 汽车 (不 考虑 手工 打造 的 察 华 
车 ) 。 不 同 的 工厂 生产 不 同 的 汽车 ， 至 马 工 三 生 产 军 马 牌子 的 车 ， 奔 
驰 工厂 生产 奔驰 牌子 的 车 。 车 不 仅 具 有 不 同 品牌 ， 还 有 不 同 的 用 途 分 
类 ， 如 商务 车 Van， 运 动 型 车 SUV 等 ， 我 们 按照 两 种 设计 模式 分 别 实现 
车 辆 的 生产 过 程 。 


30.2.1 按 抽象 工厂 模式 生产 车 辆 


按照 抽象 工厂 模式 ， 首 先 需 要 定义 一 个 抽象 的 产品 接口 即 汽 车 接 
口 ， 然 后 军马 和 奔驰 分 别 实现 该 接口 ， 由 于 它们 只 具有 了 一 个 品牌 属 
性 ， 还 没有 定义 一 个 具体 的 型 号 ， 属 于 对 象 的 抽象 层次 ， 每 个 具体 车 


型 由 其 子 类 实现 ， 如 R 系 列 的 奔驰 车 是 商务 车 ，X 系 列 的 宝马 车 属于 
SUV， 我 们 来 看 类 图 ， 如 图 30-3 所 示 。 


<<interface>> 
ICar 
+Strng getBand() 
+String get Model() 


TD 
| 
+Strin 


Pr 
A 


<<interface>> 
CarFactory 
| 


+ICar createSuv() 
+ICar createVan() 


+String getBand() 


ds 
| | 


图 30-3 车 辆 生产 的 工厂 类 图 


在 类 图 中 ， 产 品类 很 简单 ， 我 们 从 两 个 维度 看 产品 : 品牌 和 车 
型 ， 每 个 品牌 下 都 有 两 个 车 型 ， 如 至 马 SUV， 至 马 商 务 车 等 ， 同 时 我 
们 又 建造 了 两 个 工厂 ， 一 个 专门 生产 宝马 车 的 宝马 工厂 BMWFactory， 
一 个 是 生产 奔驰 车 的 奔驰 车 生产 工厂 BenzFactory。 当然 ， 汽 车 工厂 也 
有 两 个 不 同 的 维度 ， 可 以 建立 这 样 两 个 工厂 : 一 个 专门 生产 SUV 车 辆 
的 生产 工 广 ， 生 产 至 马 SUV 和 奔驰 SUV， 另 外 一 个 工矿 专门 生成 商务 
和 车， 分 别 是 宝 蕊 商务 车 和 奔驰 商务 车 ， 这 样 设计 在 技术 上 古 完 全 可 行 
的 ,但 古 在 业务 上 古 不 可 行 的 ， 为 什么 ? 这 是 因为 你 看 到 过 有 一 个 工 
广 既 能 生产 奔驰 SUV 也 能 生产 宝马 SUV 吗 ? 这 是 不 可 能 的 ， 因 为 业务 


受 限 ， 除 非 是 国内 的 山寨 工厂 。 我 们 先 来 看 产品 类 ， 汽 车 接口 如 代码 
清单 30-12 所 示 。 


代码 清单 30-12 汽车 接口 


public interface ICar { 
// 汽 车 的 生产 商 ， 也 就 是 牌子 
public String getBand() ， 
// 汽 车 的 型 号 
public String getModel(); 


在 产品 接口 中 我 们 定义 了 车 辆 有 两 个 可 以 查询 的 属性 : 品牌 和 型 
号 ， 奔 驰 车 和 宝马 车 是 两 个 不 同 品牌 的 产品 ， 但 不 够 具体 ， 只 是 知道 
它们 的 品牌 而 已 ， 还 不 能 够 实例 化 ， 因 此 还 是 一 个 抽象 类 ， 如 代码 清 
单 30-13 所 示 。 


代码 清单 30-13 抽象 宝马 车 


public abstract class AbsBMW implements ICar { 
private final static String BMW_BAND = "宝马 汽车 " ， 
// 宝 马车 
public String getBand() { 
return BMW_BAND ， 


} 
// 型 号 由 具体 的 实现 类 实现 
public abstract String getModel( ); 


抽象 产品 类 中 实现 了 产品 的 类 型 定义 ， 车 辆 的 型 号 没有 实现 ， 两 
实现 类 分 别 实现 商务 车 和 运动 型 后， 分别 如 代码 清单 30-14、 代 码 清单 
30-15 所 示 。 


代码 清单 30-14 宝马 商务 车 


public class BMWVan extends AbSsBMW { 
private final static String SEVENT_SEARIES = "7 系列 车 型 商务 


车 0， 

public String getModel() { 
return SEVENT_SEARIES ， 

} 


代码 清单 30-15 宝马 SUV 


public class BMWSuv extends AbSsBMW { 
private final static String X_SEARIES = "X 系 列车 型 SUV"， 
public String getModel() { 
return Xx_SEARIES,; 
} 


奔驰 车 与 至 马车 类 似 ， 痢 已 经 有 清晰 品牌 定义 ， 但 是 型 号 还 没有 
确认 ， 也 是 一 个 抽象 的 产品 类 ， 如 代码 清单 30-16 所 示 。 


代码 清单 30-16 抽象 奔驰 车 


public abstract class AbsBenz implements ICar { 
private final static String BENZ_BAND = "奔驰 汽车 " 
public String getBand() { 
return BENZ_BAND ， 
} 


// 具 体型 号 由 实现 类 完成 
public abstract String getModel( ); 


由 于 分 类 的 标准 是 相同 的 ， 因 此 奔驰 车 也 应 该 有 商务 车 和 运动 车 
两 个 类 型 ， 分 别 如 代码 清单 30-17 和 代码 清单 30-18 所 示 。 


代码 清单 30-17 奔驰 商务 车 


public class BenzVan extends AbsBenz { 
private final static String R_SERIES = "R 系 列 商 务 车 "， 
public String getModel() { 
return R_SERIES ， 
} 


} 
代码 清单 30-18 ”奔驰 SUV 
public class BenzSuv extends AbsBenz { 
private final static String G_SERIES = "6G 系 列 SUV"; 
public String getModel() { 
return G_SERIES ， 
} 


所 有 的 产品 类 都 已 经 实现 了 ， 剩 下 的 工作 就 是 要 定义 工厂 类 进行 
生产 ， 由 于 产品 类 型 多 样 ， 也 导致 了 必须 有 多 个 工厂 类 来 生产 不 同 产 
品 ， 首 先 就 需要 定义 一 个 抽象 工 三， 声明 每 个 工厂 必须 完成 的 职责 ， 
如 代码 清单 30-19 所 示 。 


代码 清单 30-19 抽象 工厂 


public interface CarFactory { 
// 生 产 SUV 
public ICar createSuv(); 
// 生 产 商务 车 
public ICar createVan(); 


抽象 工厂 定义 了 每 个 工厂 必须 生产 两 个 类 型 车 : SUV (运动 车 ) 
和 VAN (商务 车 ) ， 否 则 一 个 工厂 就 不 能 被 实例 化 ， 我 们 来 看 宝马 车 
工厂 ， 如 代码 清单 30-20 所 示 。 


代码 清单 30-20 宝马 车 工厂 


public class BMWFactory implements CarFactory { 
// 生 产 SUV 


public ICar createSuv() { 
return new BMWSuV( ); 
} 


// 生 产 商务 车 
public ICar createVan()t{ 

return new BMWVan( ); 
} 


很 简单 ， 你 要 我 生产 至 马 商 务 车 ， 没 问题 ， 直 接 产 生 一 个 至 马 商 
务 车 对 象 ， 返回 给 调用 者 ， 这 对 调用 者 来 说 根本 不 需要 关心 到 底 是 起 
么 生产 的 ， 它 只 要 找到 一 个 宝马 工厂 ， 即 可 生产 出 自己 需要 的 产品 
(汽车 ) 。 奔 驰 车 工厂 与 此 类 似 ， 如 代码 清单 30-21 所 示 。 


代码 清单 30-21 奔驰 车 工厂 


public class BenzFactory implements CarFactory { 
// 生 产 SUV 
public ICar createSuv() { 
return new BenzSuv( ) ; 


} 

// 生 产 商 务 车 

public ICar createVan(){ 
return new BenzVan( ) ， 

} 


产品 和 工 广 都 具备 了 ， 剩 下 的 工作 就 是 建立 一 个 场景 类 模拟 调用 
者 调用 ， 如 代码 清单 30-22 所 示 。 


代码 清单 30-22 场景 类 


public class Client { 
public static void main(String[] args) { 
// 要 求生 产 一 辆 奔驰 SUV 
System.out ， 人 辆 奔驰 SUV===" ) ， 
// 首 先 找 到 生产 奔驰 车 的 工厂 


System,out,.println("A、 找 到 奔驰 车 工矿" ) ; 
CarFactory carFactory= new BenzFactory( ) ， 


// 开 始 4 


FE 产 奔驰 SUV 


System.out.println("B、 开 始 生 产 奔驰 SUV")， 
ICar benzSuv = carFactory.createSuv(); 


//94 


EF 广元 十 ， 


展示 一 下 并 


F 辆 信息 


System.out.println("C、 生 产 出 的 汽车 如 下 : "); 
System.out ,println(" 汽 车 品牌 : "+benzSuv.getBand()); 
System,out,.println(" 汽 车 型 号 : " + 
benzSuv .getModel() ) ; 
} 


上 


运行 结果 如 下 所 示 : 


=== 要 求生 产 一 辆 奔驰 SUV=== 


A、 找 到 奔驰 车 工厂 


B、 开 始 生产 奔驰 SUV 


C、 生 产 出 的 汽车 如 下 : 


汽车 品牌 : 奔驰 汽车 


汽车 型 号 ，G 系 列 SUV 


对 外 界 调 用 者 来 说 ， 只 要 更 换 一 个 具备 相同 结构 的 对 象 ， 即 可 发 
生 非 常 大 的 改变 ， 如 我 们 原本 使 用 BenzFactory 生 产 汽车 ， 但 是 过 了 一 
段 时 间 后 ， 我 们 的 系统 需要 生产 宝马 汽车 ， 这 对 系统 来 说 不 需要 很 大 
的 改动 ， 只 要 把 工厂 类 使 用 BMWFactory 代 替 即 可 ， 立 刻 可 以 生产 出 宝 
马车 ， 注 意 这 里 生产 的 是 一 辆 完整 的 车 ， 对 于 一 个 产品 ， 上 只 要 给 出 产 
品 代码 〈 车 类 型 ) 即 可 生产 ， 抽 象 工厂 模式 把 一 辆 车 认为 是 一 个 完整 
的 、 不 可 拆 分 的 对 象 。 它 注重 完整 性 ， 一 个 产品 一 旦 找到 一 个 工厂 生 
产 ， 那 就 古 固 定 的 型 号 ， 


不 会 出 现 一 个 宝马 工厂 生产 奔驰 车 的 情况 。 


那 现在 的 问题 是 我 们 束 想 要 一 辆 混合 的 车 型 ， 如 奔驰 的 引擎 ， 宇 马 的 
车 轮 ， 那 该 怎么 处 理 呢 ? 使 用 我 们 的 建造 者 模式 ! 


30.2.2 按 建 造 者 模式 生产 车 辆 


按照 建造 者 模式 设计 一 个 生产 车 辆 需要 把 车 辆 进行 拆 分 ， 拆 分 成 
引 敬 和 车 轮 两 部 分 ， 然 后 由 建造 者 进行 建造 ， 想 要 什么 车 ， 你 只 要 有 
设计 图 纸 就 成 ， 马 上 可 以 制造 一 辆 车 出 来 。 它 注重 的 是 对 零件 的 装 
配 、 组 合 、 封 装 ， 它 从 一 个 细微 构件 装配 角度 看 待 一 个 对 象 。 我 们 来 
看 生产 车 辆 的 类 图 ， 如 图 30-4 所 示 。 


注意 看 我 们 类 图 中 的 蓝图 类 Blueprint， 它 负责 对 产品 建造 过 程 定 
义 。 有 既然 要 生产 产品 ， 那 必然 要 对 产品 进行 一 个 揪 述 ， 在 类 图 中 我 们 
定义 了 一 个 接口 来 摘 述 汽车 ， 如 代码 清单 30-23 所 示 。 


代码 清单 30-23 车 辆 产品 描述 


public interface ICar { 
// 汽 车 车 轮 


public String getwheel(); 
// 汽 车 引擎 
public String getEngine( )， 
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图 30-4 建造 者 模式 建造 车 辆 


我 们 定义 一 辆 车 必须 有 和 车轮 和 3 引擎， 具体 的 产品 如 代码 清单 30-24 
a 


代码 清单 30-24 具体 车 辆 


public class Car implements ICar { 
// 汽 车 引擎 
private String engine 
// 汽 车 车 轮 
private String wheel; 
// 一 次 性 传递 汽车 需要 的 信息 
public Car(String _engine,String _wheel)t 
this.engine = _engine; 
this.wheel = _wheel; 


} 

public String getEngine() { 
return engine,; 

} 


public String getwheel() { 
return wheel; 


} 
public String toString(){ 
return "车 的 轮子 是 : " + wheel +"\n 车 的 引擎 是 : " + 


engine; 


» 


一 个 简单 的 JavaBean 定 义 产 品 的 属性 ， 明 确 对 产品 的 搞 述 。 我 们 继 
续 来 思考 ， 因 为 我 们 的 产品 是 比较 抽象 的 ， 它 没有 指定 引擎 的 型 号 ， 
也 没有 指定 车 轮 的 牌子 ， 那 么 这 样 的 组 合 方式 有 很 多 ， 完 全 要 靠 建造 
者 来 建造 ， 建 造 者 说 要 生产 一 辆 奔驰 SUV 那 就 得 用 径 驰 的 引擎 和 奔驰 
的 车 轮 ， 该 建造 者 对 于 一 个 具体 的 产品 来 说 是 绝对 的 权威 ， 我 们 来 描 
述 一 下 建造 者 ， 如 代码 清单 30-25 所 示 。 


代码 清单 30-25 抽象 建造 者 


public abstract class CarBuilder { 
// 待 建造 的 汽车 
private ICar car; 
// 设 计 蓝 图 
private Blueprint bp; 
public Car buildCar()t{ 
// 按 照 顺序 生产 一 辆 车 
return new Car(buildEngine(),buildwheel()); 


} 

// 接 收 一 份 设计 蓝 

public void receiveBlueprint(Blueprint _bp)t{ 
this.bp = _bp; 

} 


// 查 看 蓝图 ， 只 有 真正 的 建造 者 才 可 以 查看 监 图 

protected Blueprint getBlueprint(){ 
return bp; 

} 


// 建 造 车 轮 
protected abstract String buildwheel(); 
// 建 造 引 擎 


protected abstract String buildengine(); 


看 到 Blueprint 类 了 ， 它 中 文 的 意思 是 “蓝图 >， 你 要 建造 一 辆 车 必须 
有 一 个 设计 样稿 或 者 蓝图 吧 ， 否 则 怎么 生产 ? 怎么 装配 ? 该 类 就 是 一 
个 可 参考 的 生产 样本 ， 如 代码 清单 30-26 所 示 。 


代码 清单 30-26 生产 蓝 


public class Blueprint { 
// 车 轮 的 要 求 
private String wheel; 
// 引 警 的 要 求 
private String engine; 
public String getwheel() { 
return wheel; 


} 
public void setwheel(String wheel) { 
this.wheel = wheel; 


} 
public String getEngine() { 
return engine 


} 

public void setEngine(String engine) { 
this.engine = engine; 

} 


这 和 一 个 具体 的 产品 Car 类 是 一 样 的 ? 错 ， 不 一 样 ! 它 是 一 个 是 
图 ， 十 一 个 可 以 参考 的 模板 ， 有 一 个 监 图 可 以 设计 出 非常 多 的 产品 ， 
如 有 一 个 R 系 统 的 奔驰 商务 车 设计 监 图， 我 们 就 可 以 生产 出 一 系列 的 奔 
驰 车 。 它 指导 我 们 的 产品 生产 ， 而 不 是 一 个 具体 的 产品 。 我 们 来 看 宝 
马车 建造 车 间 ， 如 代码 清单 30-27 所 示 。 


代码 清单 30-27 宝马 车 建造 车 间 


public class BMWBuilder extends CarBuilder { 
public String buildEngine() { 
return super.getBlueprint().getengine(); 


} 
public String buildwheel() { 

return super.getBlueprint().getwheel(); 
} 


这 是 非常 简单 的 类 。 只 要 获得 一 个 监 图 ， 然 后 按照 监 图 制造 引擎 
和 车 轮 即 可 ， 剩 下 的 事情 就 区 给 抽象 的 建造 者 进行 装配 。 和 奔驰 车 间 与 
此 类 似 ， 如 代码 清单 30-28 所 示 。 


代码 清单 30-28 奔驰 车 建造 车 间 


public class BenzBuilder extends CarBuilder { 
public String buildEngine() { 
return super.getBlueprint().getengine(); 


} 
public String buildwheel() { 

return super.getBlueprint().getwheel(); 
} 


两 个 建造 车 间 都 已 经 完成 ， 那 现在 的 问题 就 变 成 了 怎么 让 车 间 运 
作 ， 谁 来 编写 监 图 ? 谁 来 协调 生产 车 间 ? 谁 来 对 外 提供 最 终 产品 ? 于 
征 导 演 类 出 场 了 ， 它 不 仅仅 有 每 个 车 间 需 要 的 设计 蓝图 ， 还 具有 指导 
不 同 车 间 闭 配 顺序 的 职责 ， 如 代码 清单 30-29 所 示 。 


代码 清单 30-29 导演 类 


public class Director { 
// 声 明 对 建造 者 的 引用 
private CarBuilder benzBuilder = new BenzBuilder(); 
private CarBuilder bmwBuilder = new BMWBuilder(); 
// 生 产 奔驰 SUV 


public ICar createBenzSuv(){ 
// 制 造 出 汽车 
return createCcar(benzBuilder，"benz 的 引擎 "，"benz 的 轮 


胎 ") ; 


} 

// 生 产 出 一 辆 宝马 商务 车 
public ICar createBMWVan(){ 

return createCcar(benzBuilder，"BMw 的 引擎 "，"BMwW 的 轮 


胎 " ) ; 
// 生 产 出 一 个 混合 车 型 
public ICar createComplexCar(){ 
return createcar(bmwBuilder，"BMW 的 引擎 "，"benz 的 轮 


胎 ") ; 


} 

// 和 生产 车 辆 
private ICar createCar(CarBuilder _carBuilder,String 

engine,String wheel)t{ 

// 导 演 怀揣 蓝图 

Blueprint bp = new Blueprint(); 

bp.setEngine(engine); 

bp.setwheel(wheel); 

System.out.println(" 获 得 生产 蓝图 ")， 

_CarBuilder.receiveBlueprint(bp); 

return _carBuilder .buildCar(); 


这 里 有 一 个 私有 方法 createCar， 其 作用 是 减少 导演 类 中 的 方法 对 监 
图 的 依赖 ， 全 部 由 该 方法 来 完成 。 我 们 编写 一 个 场景 类 ， 如 代码 清单 
30-30 所 示 。 


代码 清单 30-30 场景 类 


public class Client { 
public static void main(String[] args) { 

// 定 义 出 导演 类 
Director director =new Director(); 
// 给 我 一 辆 奔驰 车 SUV 
System.out.println("=== 制 造 一 辆 奔驰 SUV===" ) ， 
ICar benzSuv = director.createBenzSuv(); 
System.out.println(benzSuv) ; 


// 给 我 一 辆 宝马 商务 车 
System.out.println("NXn=== 制 造 一 辆 宝马 商务 车 ===") 
ICar bmwvan = director.createBMwVan( ) ; 
System.out.printJln(bmwVan ) ; 

// 给 我 一 辆 混合 车 型 

System.out .printlin("\n=== 制 造 一 辆 混合 车 ===")，; 
ICar complexCar = director.createComplexCar(); 
System.out.println(complexCar); 


场景 类 只 要 找到 导演 类 


就 是 车 间 主 任 了 ) 说 给 我 制造 一 辆 这 


(也 
样 的 至 马车 ， 车 间 主 任 马上 通晓 你 的 意图 ， 设 计 了 一 个 监 图 ， 然 后 命 
建造 ， 


令 建造 车 间 拼命 加 班 加 点 寻 


终 返 回 给 你 一 件 最 新 出 品 的 产品 ， 


运行 结果 如 下 所 示 : 
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果 片 段 ， 我 们 可 以 了 立刻 生产 出 一 辆 混合 

图， 这 非常 容易 实现 。 反 观 我 们 的 抽象 工厂 模式， 
的 ， 因 为 它 更 关注 的 是 整体 ， 而 不 关注 到 奈 用 
马 引 警 ， 而 我 们 的 建造 者 模式 却 可 以 很 容易 地 实 
更 了 ， 我 们 就 可 以 立刻 跟 进 ， 生 产 出 客户 需要 
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30.2.3 最 佳 实践 


注意 看 上 面 的 描述 ， 我 们 在 抽象 工厂 模式 中 使 用 “工厂 ”来 描述 构 
建 者 ， 而 在 建造 者 模式 中 使 用 “车 间 * 来 描述 构建 者 ， 其 实 我 们 已 经 在 
说 它们 两 者 的 区 别 了 ， 抽 象 工厂 模式 就 好 比 是 一 个 一 个 的 工厂 ， 宝 马 
车 工厂 生产 宝马 SUV 和 宝马 VAN， 和 奔驰 车 工厂 生产 奔驰 车 SUV 和 奔驰 
VAN， 它 是 从 一 个 更 高 层次 去 看 对 象 的 构建 ， 具 体 到 工厂 内 部 还 有 很 
多 的 车 间 ， 如 制造 引 警 的 车 间 、 装 配 引 警 的 车 间 等 ， 但 这 些 都 是 隐藏 
在 工厂 内 部 的 细节 ， 对 外 不 公布 。 也 就 是 对 领导 者 来 说 ， 他 只 要 关心 
一 个 工厂 到 底 是 生产 什么 产品 的 ， 不 用 关心 具体 怎么 生产 。 而 建造 者 
模式 就 不 同 了 ， 它 是 由 车 间 组 成 ， 不 同 的 车 间 完 成 不 同 的 创建 和 装配 
任务 ， 一 个 完整 的 汽车 生产 过 程 需要 引擎 制造 和 车间、 引擎 装配 车 间 的 
配合 才能 完成 ， 它 们 配合 的 基础 就 是 设计 蓝图 ， 而 这 个 蓝图 是 掌握 在 
车 间 主 任 (导演 类 ) 手中 ， 它 给 建造 车 间 什 么 蓝图 就 能 生产 什么 产 
品 ， 建 造 者 模式 更 关心 建造 过 程 。 虽 然 从 外 界 看 来 一 个 车 间 还 是 生产 


车 辆 ， 但 站 这 个 车 间 的 转型 是 非常 快 的 ， 只 要 重新 设计 一 个 监 岁 ， 即 
可 产生 不 同 的 产品 ， 这 有 赖 于 建造 者 模式 的 功劳 。 


相对 来 说 ， 抽 象 工厂 模式 比 建造 者 模式 的 尺度 要 大 ， 它 关注 产品 
整体 ， 而 建造 者 模式 关注 构建 过 程 ， 因 此 建造 者 模式 可 以 很 容易 地 构 
建 出 一 个 加 新 的 产品 ， 只 要 导演 类 能 够 提供 具体 的 工艺 流程 。 也 正 因 
为 如 此 ， 两 者 的 应 用 场景 截然 不 同 ， 如 采 布 望 屏蔽 对 象 的 创建 过 程 ， 
只 提供 一 个 封装 民 好 的 对 象 ， 则 可 以 选择 抽象 工厂 方法 模式 。 而 建造 
者 模式 可 以 用 在 构件 的 妆 配 方面 ， 如 通过 妆 配 不 同 的 组 件 或 者 相同 组 
件 的 不 同 顺序 ， 可 以 产生 出 一 个 新 的 对 象 ， 它 可 以 产生 一 个 非常 灵活 
的 染 构 ， 方 便 地 扩展 和 维护 系统 。 


第 31 章 ”结构 类 模式 大 PK 


结构 类 模式 包括 适配器 模式 、 桥 粱 模式、 组 合 模式 、 狐 饰 模式 、 
门面 模式 、 有 至 元 模式 和 代理 模式 。 为 什么 叫 结构 类 模式 呢 ? 因 为 它们 
都 是 通过 组 合 类 或 对 象 产 生 更 大 结构 以 适应 更 高 层次 的 逻辑 需求 。 我 
们 来 分 析 以 下 几 个 模式 的 相似 点 和 不 同 点 。 


31.1 代理 模式 VS 装饰 模式 


对 于 两 个 模式 ， 前 先 要 说 的 是 ， 沪 饰 模式 束 是 代理 模式 的 一 个 特 
殊 应 用 ， 两 兰 的 共同 点 是 都 具有 相同 的 接口 ， 不 同 点 则 是 代理 模 陈 着 
重 对 代理 过 程 的 控制 ， 而 疼 师 模式 则 是 对 类 的 功能 进行 加 强 或 减弱 ， 
筷 看 重 类 的 功能 变化 ， 我 们 举例 来 说 明 它 们 的 区 别 。 


31.1.1 代理 模式 


一 个 著名 的 短跑 运动 员 有 目 己 的 代理 人 。 如 果 你 很 仰慕 他 ， 你 找 
运动 员 说 “你 跑 个 我 看 看 ”"， 运 动员 肯定 不 搭理 你 ， 不 过 你 找到 他 的 代 
理 人 束 不 一 样 了 ， 你 可 能 和 代理 人 比较 熟 ， 可 以 称 兄 道 弟 ， 这 个 忙 代 
理 人 还 是 可 以 帮 有 的 ， 于 是 代理 人 同意 让 你 欣赏 运动 员 的 练习 赛 ， 这 对 
你 来 说 已 经 钙 时 大 的 采油 了 。 我 们 来 看 类 图 ， 如 图 31-1 所 示 。 
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Runner 


RunnerAgent 
-[Runner runner 


+RunnerAgent(IRunner runner) 


图 31-1 运动 员 跑 步 


这 是 一 个 套用 代理 模式 的 简单 应 用 ， 非 常 简单 ! 一 个 对 象 ， 然 后 
再 是 自己 的 代理 。 我 们 先 来 看 一 下 代码 ， 先 看 抽象 主题 类 ， 如 代码 清 
单 31-1 所 示 。 


代码 清单 31-1 抽象 运动 员 


public interface IRunner { 
// 运 动员 的 主要 工作 就 是 跑步 
public void run(); 


} 


一 个 具体 的 短跑 运动 员 跑 步 是 很 潇 酒 的 ， 如 代码 清单 31-2 所 示 。 


代码 清单 31-2 运动 员 跑步 


public class Runner implements IRunner { 
public void run() { 
System.out .println(" 运 动员 跑步 : 动作 很 潇洒 " ) ; 
} 


看 看 现在 的 明星 运动 员 ， 一 般 都 有 自己 的 代理 人 人， 要么 是 专职 
的 ， 要 么 就 是 自己 的 教练 兼职 ， 那 我 们 来 看 看 代理 人 的 职责 ， 如 代码 
清单 31-3 所 示 。 


代码 清单 31-3 代理 人 


public class RunnerAgent implements IRunner { 
private IRunner runner ; 
public RunnerAgent(IRunner _runner)t{ 
this.runner = _runner; 


} 
// 代 理 人 是 不 会 跑 的 
public void run() { 
Random rand = new Random( ) ; 
if(rand.nextBoolean())t{ 
System,out,.println(" 代 理 人 同意 安排 运动 员 跑步 ") ; 
runner .run( ) ; 


}elsef 


System.out.println(" 代 理 人 心情 不 好 ， 不 安排 运动 员 


跑步 " ) ; 


我 们 只 是 定义 了 一 个 代理 人 ， 并 没有 明确 定义 是 哪 一 个 运动 员 的 
代理 ， 需 要 在 运行 时 指定 被 代理 者 ， 而 且 我 们 还 在 代理 人 的 run 方 法 中 
做 了 判断 ， 想 让 被 代理 人 跑步 束 跑 步 ， 不 乐意 就 拒绝 ， 对 于 主题 类 的 
行为 是 否 可 以 发 生 ， 代 理 类 有 绝对 的 控制 权 。 我 们 编写 一 个 场景 类 来 
模拟 这 种 情况 ， 如 代码 清单 31-4 所 示 。 


代码 清单 31-4 场景 


public class Client { 
public static void main(String[] args) { 
// 定 义 一 个 短跑 运动 员 
IRunner liu = new Runner(); 


// 定 义 1iu 的 代理 人 

IRunner agent = new RunnerAgent(1iu); 

// 要 求 运 动员 跑步 

System.out .println("==== 客 人 找到 运动 员 的 代理 要 求 其 去 跑步 


agent .run( ) ， 


由 于 我 们 使 用 了 随机 数 产 生 模 拟 结 采 ， 因 此 运行 结果 有 两 种 可 能 
情况 ， 第 一 种 情况 如 下 所 示 : 


==== 客 人 找到 运动 员 的 代理 要 求 其 去 跑步 === 


代理 人 同意 安排 运动 员 跑步 


运动 员 跑 步 : 动作 很 潇洒 


---- 客 人 找到 运动 员 的 代理 要 求 其 去 跑步 =-- 


代理 人 心情 不 好 ， 不 安排 运动 员 跑步 


不 管 是 哪 种 情况 ， 我 们 都 证 实 了 代理 的 一 个 功能 : 在 不 改变 接口 
的 前 提 下 ， 对 过 程 进 行 控 制 。 在 我 们 例子 中 ， 运 动员 要 不 要 跑步 是 由 
代理 人 决定 的 ， 代 理 人 说 跑步 束 跑 步 ， 说 不 跑 束 不 跑 ， 它 有 绝对 判断 
要 


31.1.2 装饰 模式 


如 有 条 使 用 雄师 模式 ， 我 们 该 怎么 实现 这 个 过 程 呢 ? 小 饰 模式 钙 对 
类 功能 的 加 强 ， 怎 么 加 强 呢 ? 增强 跑步 速度 ! 在 屁股 后 面 安 装 一 个 顺 
气动 力 装置 ， 类 似 火 箭 的 喷气 装置 ， 那 速度 变 得 很 快 ，《 蜂 蛛 侠 》 中 
的 那个 反面 角色 不 束 是 这 样 的 吗 ? 好 ， 我 们 来 看 类 图 ， 如 图 31-2 所 示 。 
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-IRunner runner() 


+RunnerWithJet(IRunner runner) 


图 31-2 增强 运动 员 的 功能 


很 惊讶 ?这 个 代理 模式 完全 一 样 的 类 图 ? 是 的 ， 完 全 一 样 ! 不 过 
其 实现 的 意图 却 不 同 ， 我 们 先 来 看 代码 ，IRunner 和 Runner 与 代理 模式 
相同 ， 详 见 代 码 清单 31-1 和 代码 清单 31-2 所 示 ， 在 此 不 再 资 述 。 我 们 来 
看 装饰 类 RunnerWithJet， 如 代码 清单 31-5 所 示 。 


代码 清单 31-5 装饰 类 


public class RunnerwithJet implements IRunner { 
private IRunner runner; 
public RunnerwithJet(IRunner _runner)t{ 
this.runner = _runner; 


public void run() { 
System.out.println(" 加 快运 动员 的 速度 为 运动 员 增 加 喷气 装 


二 


runner .run( ) ; 


这 和 代理 模式 中 的 代理 类 也 是 非常 相似 的 ， 只 是 疼 炳 类 对 类 的 行 
为 没有 决定 权 ， 只 有 增强 作用 ， 也 吏 是 说 它 不 决定 被 代理 的 方法 是 否 
执行 ， 它 只 是 再 次 增加 被 代理 的 功能 。 我 们 来 看 场景 类 ， 如 代码 请 单 


31-6 所 示 。 


代码 清单 31-6 场景 类 


public class Client { 
public static void main(String[] args) { 

// 定 义 运 动员 
IRunner liu = new Runner(); 
// 对 其 功能 加 强 
liu = new RunnerwWithJet(1iu); 
// 看 看 它 的 跑步 情况 如 何 
System.out .println("=== 增 强 后 的 运动 员 的 功能 ===") 
liu.run(); 


运行 结果 如 下 所 示 : 


=== 增 强 后 的 运动 员 的 功能 === 


加 快运 动员 的 速度 ;为 运动 员 增 加 喷气 装置 


运动 员 跑 步 : 动作 很 潇洒 
注意 思考 一 下 我 们 的 程序 ， 我 们 通过 增加 了 一 个 装饰 类 ， 束 完成 
了 对 原 有 类 的 功能 增加 ， 由 一 个 普通 的 短跑 运动 员 变 成 了 带 有 了 喷气 装 
置 的 超人 运动 员 ， 其 速度 岂 是 普通 人 能 相 比 的 ? ! 


31.1.3 最 佳 实践 


通过 例子 ， 我 们 可 以 看 出 代理 模式 和 汤 饰 模式 有 非常 相似 的 地 
方 ， 甚 至 代码 实现 都 非常 相似 ， 特 别 是 流 饰 模式 中 省 略 抽 象 冯 饰 角色 
， 两 者 代码 基本 上 相同 ， 但 十 还 是 有 细微 的 差别 。 


Hl 


代理 模式 是 把 当前 的 行为 或 功能 委托 给 其 他 对 象 执行 ， 代 理 类 人 负 
责 搂 口 限定 : 和 是否 可 以 调用 真实 角色 ， 以 及 是 否 对 发 送 到 真实 角色 的 
消息 进行 变形 处 理 ， 它 不 对 被 主题 角色 〈 也 就 是 被 代理 类 ) 的 功能 做 
任何 处 理 ， 保 证 原 半 原味 的 调用 。 代 理 模 式 使 用 到 极致 开发 融 是 
AOP， 这 征 各 位 采用 Spring 架构 开发 必然 要 使 用 到 的 技术 ， 它 束 是 使 用 
了 代理 和 反射 的 技术 。 


痛 炳 模式 是 在 要 保证 接口 不 变 的 情况 下 加 强 类 的 功能 ， 它 保证 的 
征 被 修饰 的 对 象 功能 比 原 始 对 象 丰富 (当然 ， 也 可 以 减弱 ) ， 但 不 做 
准 入 条 件 判断 和 准 入 参数 过 滤 ， 如 是 否 可 以 执行 类 的 功能 ， 过 滤 输 入 


参数 是 否 合 规 等 ， 这 不 是 竣 师 模式 关心 的 。 


代理 模式 在 Java 的 开发 中 俯 拾 几 是 ， 是 大 家 非常 熟悉 的 模式 ， 应 用 
非常 广泛 ， 而 凌 所 模 式 是 一 个 比较 拘 刘 的 模式 ， 在 实际 应 用 中 接触 比 
较 少 ， 但 是 也 有 不 少 框 染 项 目 使 用 了 小 饰 模式 ， 例 如 在 JDK 的 java.io.* 
包 中 束 大 量 使 用 雄师 模式 ， 类 似 如 下 的 代码 : 


OutputStream out = new Data0utputStream (new FileOutputStream 
("test.txt") ) 


这 是 装饰 模式 的 一 个 典型 应 用 ， 使 用 DataOutputStream 封 闭 了 一 个 
FileOutputStream， 以 方便 进行 输出 流 处 理 。 


31.2 装饰 模式 VS 适配器 模式 


淡 饰 模式 和 适 配 右 模式 在 通用 类 图 上 没有 太 多 的 相似 点 ， 压 别 比 
较 大 ， 但 是 它们 的 功能 有 相似 的 地 方 : 都 是 包装 作用 ， 都 是 通过 委托 
方式 实现 其 功能 。 不 同 点 是 : 痛 炳 模式 包 关 的 是 目 己 的 兄弟 类 ， 隶 属 
于 同一 个 家 族 (相同 接口 或 父 类 ) ， 适 配器 模式 则 修饰 非 血缘 关系 
类 ， 把 一 个 非 本 家 族 的 对 象 伪装 成 本 家 族 的 对 象 ， 注 意 是 伪装 ， 因 此 
它 的 本 质 还 古 非 相同 接口 的 对 象 。 


大 家 都 应 该 听 过 丑小鸭 的 故事 吧 ， 我 们 今天 束 用 这 两 种 模式 分 别 
讲述 丑小鸭 的 故事 。 话 说 鸭 妈 妈 有 5 个 孩子 ， 其 中 4 个 孩子 都 是 黄白 相 
间 的 颜色 ， 而 最 小 的 那 只 也 束 是 叫做 丑 小 芍 的 那 只 ， 古 纯 日 色 的 ,与 
见 第 姐妹 不 相同 ， 在 遭受 了 诸多 的 嘲讽 和 计 笑 后 ， 最 终于 小 鸭 变 成 了 
一 只 美丽 的 天 筷 。 那 我 们 如 何 用 两 种 不 同 模式 来 描述 这 一 故事 呢 ? 


31.2.1 用 凑 炳 模式 朱 述 丑小鸭 


用 汤 饰 模式 来 接 述 丑 小 阳 ， 目 先 束 要 肯定 丑 小 药 十 一 只 天 鹅 ， 只 
征 因 为 她 小 或 者 是 鸭 妈 妈 的 无 知 才 没 有 被 认 出 是 天 斤 ， 经 过 一 段 时 间 
后 ， 它 逐步 变 成 一 个 漂亮 、 自 信 、 优 美的 白天 筷 。 根 据 分析 我 们 可 以 
这 样 设 计 ， 移 设计 一 个 丑小鸭 ， 然 后 根据 时 间 先 后 来 进行 不 同 的 美化 


处 理 ， 怎 么 美化 呢 ? 先 长 出 漂亮 的 羽毛 ， 然 后 逐 
不 同行 为 ， 如 飞行 ， 最 终 在 具备 了 所 有 的 行为 后 
的 日 天 鹅 了， 我 们 来 看 类 图 ， 如 图 31-3 所 示 。 


<<interface>> 
Swan 


+void fly() 
+vold cry() 
+void desAppaearance() 


步 展 现 出 异 于 鸭子 的 
， 它 就 成 为 一 只 纯粹 


Client 
Ee====== = 
| | 


Decorator 
-Swan swan 


+Decorator(Swan swan) 
+void fly() 

+void cry() 

t+void desAppaearance() 


外 形 修饰 、 


BeautifyAppearance 
+BeautifyAppearance(Swan swan) 
+void desAppaearance() 


图 31-3 雄 饰 模式 实现 丑小鸭 


类 图 比较 简单 ， 非 常 标准 的 小 饰 模式 。 我 们 按照 故事 的 情 广 发 展 
一 步 一 步 地 实现 程序 。 初 期 的 时 候 ， 了 丑小鸭 表 现 得 很 另类 ， 叫 声 不 
同 ， 外 形 不 同 ， 致 使 周围 的 亲戚 、 朋 友 都 对 她 鄙 祝 ， 那 我 们 来 建立 这 


个 过 程 ， 由 于 丑 小 卜 的 本 质 就 是 一 个 天 牲 ， 我 们 就 先生 成 一 个 天 鹅 的 
接口 ， 如 代码 清单 31-7 所 示 。 


代码 清单 31-7 天 筷 接 口 


public interface Swan { 
// 天 秽 会 飞 
public void fly(); 
// 天 鹅 会 叫 
public void cry(); 
// 天 和 殷 都 有 漂亮 的 外 表 


public void desAppaearance( )，; 


我 们 定义 了 天 筷 的 行为 ， 都 会 飞行 、 会 叫 ， 并 且 可 以 搬 述 她 们 漂 
亮 的 外 表 。 了 丑小鸭 是 一 只 日 天 痢 ， 是 "is-a" 的 关系 ， 也 就 是 需要 实现 这 
个 接口 了 ， 其 实现 如 代码 清单 31-8 所 示 。 


代码 清单 31-8 丑小鸭 


public class UglyDuckling implements Swan { 
// 丑 小 鸭 的 叫 声 
public void cry() { 
System,out,.println(" 叫 声 是 克 史 一 克 噜 一 克 噜 " ) ; 


} 
// 了 丑小鸭 的 外 形 
public void desAppaearance() { 
System.out .println(" 外 形 是 脏 分 兮 的 白色 ， 毛 昔 昔 的 大 脑袋 ") ; 


} 

// 丑 小 四 还 比较 小 ， 不 能 

public void fly() { 
System.out.printLn(" 不 能 飞行 ") ; 


丑小鸭 具备 了 天 鹅 的 所 有 行为 和 属性 ， 因 为 她 本 来 就 是 一 只 白天 
的 ， 只 是 因为 她 太 小 了 还 不 能 飞行 ， 也 不 能 照顾 目 己 ， 所 以 丑 丑 的 ， 
在 经 过 长 时 间 的 流浪 生活 后 ， 丑 小 鸭 长 大 了 。 终 于 有 一 天 ， 她 发 现 目 
己 竟 然 变 成 了 一 只 美丽 的 白天 牧 ， 有 着 漂亮 、 洁 白 的 羽毛 ， 而 且 还 可 
以 飞行 ， 这 完全 是 一 种 升华 行为 。 我 们 来 看 看 她 的 行为 《飞行 ) 和 属 
性 (外 形 ) 是 如 何 加 强 的 ， 先 看 抽象 的 装饰 类 ， 如 代码 清单 31-9 所 示 。 


代码 清单 31-9 抽象 装饰 类 


public class Decorator implements Swan { 
private Swan swan; 
// 修 饰 的 是 谁 
public Decorator(Swan _swan)t{ 
this. swan =_swan; 


} 
public void cry() { 
swan.cry(); 


} 
public void desAppaearance() { 
swan.desAppaearance( ); 


} 

public void fly() { 
swan.fly(); 

} 


这 是 一 个 非常 简单 的 代理 模式 。 我 们 再 来 看 丑小鸭 是 如 何 开 始 变 
得 美丽 的 ， 变 化 是 由 外 及 里 的 ， 有 了 漂亮 的 外 表 才 有 内 心 的 实质 变 
化 ， 如 代码 清单 31-10 所 示 。 


代码 清单 31-10 外 形 美化 


public class BeautifyAppearance extends Decorator { 
// 要 美化 谁 


public BeautifyAppearance(Swan _Swan){ 
super (_swan); 


} 

// 外 表 美化 处 理 

Q@Override 

public void desAppaearance( ){ 
System.out.println(" 外 表 是 纯 白色 的 ， 非 


过 


4 
员 


车 人 


缴 


C 


丑小鸭 最 后 发 现 目 己 还 能 飞行 ， 这 是 一 个 行为 突破 ， 和 是 对 原 有 行 
为 “不 会 飞行 ”的 一 种 强化 ， 如 代码 清单 31-11 所 示 。 


代码 清单 31-11 强化 行为 


public class StrongBehavior extends Decorator { 
// 强 化 谁 
public StrongBehavior (Swan _swan)t{ 
super (_swan); 


} 
// 会 飞行 了 
public void fly(){ 
System.out.println(" 会 飞行 了 ! "); 
} 


所 有 的 故事 元 素 我 们 都 具备 了 ， 束 等 有 人 来 讲 故 事 了 ， 场 景 类 如 
代码 清单 31-12 所 示 。 


代码 清单 31-12 场景 


public class Client { 
public static void main(String[] args) { 
// 很 久 很 久 以 前 ， 这 里 有 一 个 丑陋 的 小 鸭子 
System.out.println("=== 很 久 很 久 以 前 ， 这 里 有 一 只 丑陋 的 小 上 


子 ===" ; 
Swan duckling = new UglyDuckling(); 
// 展 示 一 下 小 鸭子 
duckling.desAppaearance(); // 小 鸭子 的 外 形 


duckling,cry(); /7/ 小 鸭子 的 叫 声 
duckling.fly(); // 小 鸭子 的 行为 
System.out .printlin("\n=== 小 鸭子 终于 发 现 自己 是 一 只 天 鹅 


// 首 先 外 形变 化 了 
duckling = new BeautifyAppearance(duckling); 
// 其 次 行为 也 发 生 了 改变 

duckling = new StrongBehavior(duckling); 

// 虽 然 还 是 叫 丑 小 鸭 ， 但 是 已 经 发 生 了 很 大 变化 
duckling.desAppaearance( ); /7/ 小 鸭子 的 新 外 形 
duckling,cry(); /7/ 小 鸭子 的 新 叫 声 
duckling,fly(); /小 鸭子 的 新 行为 


证 


运行 结果 如 下 所 示 : 


=== 很 久 很 久 以 前 ， 这 里 有 一 只 丑陋 的 小 鸭子 === 


外 形 是 脏 兮 今 的 白色 ， 毛 苷 攻 的 大 脑袋 


叫 声 是 克 史 一 一 克 史 一 一 区 史 


不 能 飞行 


=== 小 鸭子 终于 发 现 自己 是 一 只 天 笋 ==== 


外 表 是 纯 日 色 的 ， 非 常 车 人 言 爱 ! 


叫 声 是 殉 史 一 一 克 哈 一 一 克 蛤 


使 用 效 饰 模式 描述 丑小鸭 暗 变 的 过 程 是 如 此 简单 ， 它 关注 了 对 象 
功能 的 强化 ， 是 对 原始 对 象 的 行为 和 属性 的 修正 和 加 强 ， 把 原本 被 人 
层 视 、 冷 落 的 丑小鸭 通过 两 次 强化 处 理 最 终 转 变 为 受 人 喜爱 、 淡 慕 的 
日 天 揭 。 


31.2.2 用 适配器 模式 实现 丑 小 胸 


采用 适配器 模式 实现 丑 小 鸥 变 成 日 天 鹅 的 过 程 要 从 胸 妈 妈 的 角度 
来 分 析 ， 胸 妈妈 有 5 个 孩子 ， 它 认为 这 5 个 孩子 部 是 她 的 后 代 ， 痢 是 肛 
类 ， 但 是 实际 上 是 有 一 只 〈 也 就 是 丑小鸭 ) 不 是 真正 的 鸭 类 ， 她 是 一 
只 小 日 天 获 ， 殉 像 《 木 兰 辞 》 中 说 的 “ 雄 免 脚 扑 角 ， 雌 免 腿 迷 离 。 双 免 
傍 地 走 ， 安 能 辩 我 是 雄 雌 ? "同样 ， 因 为 太 小 ， 差 别 太 细 微 ， 很 难 分 
辨 ， 导 致 鸭 妈 妈 认 为 她 是 一 只 鸭子 ， 从 鸭子 的 审美 观 来 看 ， 丑 小 鸭 是 
丑陋 的 。 通 过 分 机， 我 们 要 做 的 融 是 要 设计 两 个 对 象 : 有 鸭 和 天 狼 ， 然 
后 鸭 妈 妈 把 一 只 天 拆 看 成 了 小 鸭子 ， 了 最 终 时 间 到 来 的 时 候 丑 小 鸭 变 成 
了 日 天 鹅 。 我 们 来 看 类 图 ， 如 图 31-4 所 示 。 
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<<Interface>> 
Duck 
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+vold cry() 
+Vvold desAppearance() 


<<interface>> 
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+Vold cry() 
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+vold desBehavior() 
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图 31-4 适 配 历 模式 实现 丑小鸭 


Duckling UglyDuckling White Swan 


类 图 非常 傈 单 ， 我 们 定义 了 两 个 接口 : 蝎 类 接口 和 天 物 类 接口 ， 
然后 建立 了 一 个 适配器 UglyDuckling， 把 一 只 白天 鹅 封装 成 了 小 由 子 。 
我 们 来 看 代码 ， 先 看 有 网 类 接口 ， 如 代码 清单 31-13 所 示 。 


代码 清单 31-13 了 鸭 类 接口 


public interface Duck { 
// 会 叫 
public void cry(); 
// 了 鸭子 的 外 形 
public void desAppearance( ) ， 
// 描 述 鸭子 的 其 他 行为 


public void desBehavior(); 


机 类 有 3 个 行为 ， 一 个 是 鸭 会 叫 ， 一 个 是 外 形 摘 述 ， 还 有 一 个 年 绿 
合 性 的 其 他 行为 接 述 ， 例 如 会 游泳 等 。 我 们 来 看 虹 妈 妈 的 4 个 正宗 孩 
子 ， 如 代码 清单 31-14 所 示 。 


代码 清单 31-14 小 鸭子 


public class Duckling implements Duck { 
public void cry() { 
System,out,.println(" 叫 声 是 嘎 一 嘎 一 嘎 " ) ， 


} 
public void desAppearance() { 
System.out.println(" 外 形 是 黄白 相间 ， 噶 长 "); 


} 

// 鸭 子 的 其 他 行为 ， 如 游泳 

public void desBehavior(){ 
System.out .println(" 会 游泳 ") ; 


4 只 正宗 的 小 鸭子 形象 已 经 清晰 地 定义 出 来 了 。 鸭 妈妈 还 有 一 个 孩 
子 ， 束 是 另类 的 丑 小 聊 ， 她 实际 是 一 只 日 天 斤 。 我 们 先 定义 出 日 天 
的 ， 如 代码 请 单 31-15 所 示 。 


代码 清单 31-15 白天 鹅 


public class WhiteSwan implements Swan { 
// 昌 天 笋 的 叫 声 
public void cry() { 
System,out,.println(" 叫 声 是 克 史 一 克 史 一 克 噜 " ) ; 


} 

// 白 天 鹅 的 外 形 

public void desAppaearance() { 
System.out.println(" 外 形 是 纯 白色 ,车 人 喜爱 "); 


} 

// 天 我 是 能 够 飞行 的 

public void fly() { 
System,out,.println(" 能 够 飞行 ") ， 


但 是 ， 肛 妈妈 却 不 认为 目 己 这 个 男 类 的 孩子 是 日 天 鹅 ， 它 从 目 己 


的 观点 出 发 ， 认 为 她 很 丑陋 ， 有 碍 目 己 的 脸面 ， 于 是 驱赶 她 一 一 肛 妈 
妈 把 这 只 小 天 物 误 认为 一 只 鸭 。 我 们 来 看 实现 ， 如 代码 清单 31-16 所 


修 ° 


代码 清单 31-16 把 白天 鹅 当 做 小 鹊 子 看 待 


public class UglyDuckling extends WhiteSwan implements Duck { 


// 了 丑小鸭 的 叫 声 
public void cry() { 
Super .cry(); 


} 

// 导 小 贞 的 外 形 

public void desAppearance() { 
super .desAppaearance( ) ， 


} 
// 丑 小 鸭 的 其 他 行为 
public void desBehavior(){ 
// 丑 小 鸭 不 公会 游泳 
System.out .println(" 会 游泳 ")， 
// 还 会 飞行 
super .fly( ); 


天 鹅 被 看 成 了 鸭子 ， 有 点 峻 珍 天 物 的 感觉 。 我 们 再 来 创建 一 个 场 


景 类 来 摘 述 这 一 场景 ， 如 代码 清音 31-17 所 示 。 


代码 清单 31-17 场景 > 


public class Client { 


public static void main(String[] args) { 


// 鸭 妈妈 有 5 个 孩子 ， 其 中 4 个 都 是 一 个 模 检 


System.out .println("=== 妈 妈 有 五 个 孩子 ， 其 中 


四 个 模 术 


的 : = 
Duck duck = new Duckling(); 
duck.cry(); // 小 鸭子 的 叫 声 
duck,desAppearance(); // 小 鸭子 的 外 形 
duck,desBehavior() ;， // 小 鸭子 的 其 他 行为 


System,out,.println("Xn=== 一 只 独特 的 小 鸭子 ， 模 样 是 这 检 

的 : = 
Duck uglyDuckling = new UglyDuckling(); 
uglyDuckling .cry(); /了 丑小鸭 的 叫 声 
uglyDuckling.desAppearance(); /7 丑小鸭 的 外 形 
uglyDuckling.desBehavior(); // 丑 小 鸭 的 其 他 行为 

} 
} 
运行 结果 如 下 所 示 : 


=== 妈 妈 有 5 个 孩子 ， 其 中 4 个 模样 是 这 样 的 : 


叫 声 是 嘎嘎 嘎 


外 形 是 黄白 相间 ， 嘴 长 


=== 一 只 独特 的 小 鸭子 ， 模 样 是 这 样 的 : 


叫 声 是 克 史 一 一 克 史 一 一 区 史 


外 形 是 纯 白 色 ， 若 人 喜爱 


会 游泳 

能 够 飞行 

可 怜 的 小 天 牧 补 认为 是 一 只 丑陋 的 小 鸭子 ， 造 物 弄 人 呀 ! 采用 适 
配 磊 模式 讲述 丑 小 罗 的 故事 ， 我 们 百 先 观察 到 的 是 有 蝎 与 天 筷 的 不 同 
点 ， 建 立 了 不 同 的 接口 以 实现 不 同 的 物种 ， 然 后 在 需要 的 时 候 (根据 


故事 情 世 ) 把 一 个 物种 伪 猴 成 矿 外 一 个 物种 ， 实 现 不 同 物种 的 相同 处 
理 过 程 ， 这 就 是 适配器 模式 的 设计 意图 。 


31.2.3 最 佳 实践 


我 们 用 两 个 模式 实现 了 了 丑小鸭 的 美丽 虹 变 。 我 们 发 现 : 这 两 个 模 
式 有 较 多 的 不 同 点 。 


e 意图 不 同 


装饰 模式 的 意图 是 加 强 对 象 的 功能 ， 例 子 中 就 是 把 一 个 丑 弱 的 小 
天 鹅 强 化 成 了 一 个 美丽 、 目 信 的 白天 鹅 ， 它 不 改变 类 的 行为 和 属性 ， 
只 是 增加 (当然 了 ,减弱 类 的 功能 也 是 可 能 存在 的 ) 功能 ， 使 美丽 更 
加 美丽 ， 强 壮 更 加 强壮 ， 安 全 更 加 安全 ;而 适配器 模式 关注 的 则 是 转 
化 ， 它 的 主要 意图 是 两 个 不 同 对 象 之 间 的 转化 ， 它 可 以 把 一 个 天 鹅 转 
化 为 一 个 小 鸭子 看 待 ， 也 可 以 把 一 只 小 鸭子 看 成 是 一 只 天 牧 ( 那 信 计 要 
在 小 鸭子 的 育 上 凑 个 螺旋 菜 了 )， 它 关注 转换 。 


e 施 与 对 象 不 同 


冯 炳 模式 冯 饰 的 对 象 必须 是 目 己 的 同宗 ， 也 束 是 相同 的 接口 或 父 
类 ， 只 要 在 具有 相同 的 属性 和 行为 的 情况 下 ， 才 能 比较 行为 是 增加 还 
征 减 弱 ; 适 配 亏 模式 则 必须 是 两 个 不 同 的 对 象 ， 因 为 它 着 重 于 转换 ， 


只 有 两 个 不 同 的 对 象 才 有 转换 的 必要 ， 如 果 是 相同 对 象 还 转换 什 


0 


e 场景 不 同 


冯 师 模式 在 任何 时 候 都 可 以 使 用 ， 只 要 是 想 增 强 类 的 功能 ， 而 适 
配器 模式 则 是 一 个 补救 模式 ， 一 般 出 现在 系统 成 熟 或 已 经 构建 完毕 的 
项 目 中 ， 作 为 一 个 紧急 处 理 手段 采用 。 


e 扩展 性 不 同 


淡 饰 模式 很 容易 扩展 ! 今天 不 用 这 个 修 电 ， 好 ， 去 挥 ;， 明 天 想 再 
使 用 ， 好， 加 上 。 这 都 没有 问题 。 而 且 泌 饰 类 可 以 继续 扩展 下 去 ; 但 
古 适配器 模式 束 不 同 了 ， 它 在 两 个 不 同 对 象 之 间架 起 了 一 座 沟 通 的 桥 
梁 ， 建 立 容易 ， 去 挥 束 比较 困难 了 ， 和 需要 从 系统 整体 考虑 十 否 能 够 撤 
销 。 


第 32 章 ”行为 类 模式 大 PK 


行为 类 模式 包括 责任 链 模式 、 命 令 模式 、 解 释 邵 模式 、 迭 代 玲 模 
式 、 中 介 者 模式 、 备 还 孙 模 式 、 观 察 者 模式 、 状 态 模 式 、 策 略 模式 、 
模板 方法 模式 、 访 问 者 模式 。 该 组 真 可 谓 是 人 才 济 阐 ， 高 手 如 云 。 行 
为 类 模式 的 11 个 模式 基本 上 都 是 大 家 耳熟能详 的 ， 而 且 它们 之 间 还 有 
很 多 的 相似 点 ， 特 别 是 一 些 扩展 部 分 束 更 加 相似 了 ， 我 们 挑选 儿 个 比 
较 重要 的 模式 进行 对 比 说 明 。 


32.1 命令 模式 VS 策略 模式 


命令 模式 和 策略 模式 的 类 图 确实 很 相似 ， 只 是 命令 模式 多 了 一 个 
接收 者 (Receiver) 和 角色。 它们 虽然 同 为 行为 类 模式 ,但 是 两 者 的 区 别 
还 是 很 明显 的 。 策 略 模式 的 意图 是 封装 算法 ， 它 认为 “算法 ”已 经 是 一 
个 完整 的 、 不 可 拆 分 的 原子 业务 (注意 这 里 是 原子 业务 ， 而 不 是 原子 
对 象 ) ， 即 其 意图 是 让 这 些 算法 独立 ， 并 且 可 以 相互 替换 ， 让 行为 的 
变化 独立 于 拥有 行为 的 客户 ;而 命令 模式 则 是 对 动作 的 解 稍 ， 把 一 个 
动作 的 执行 分 为 执行 对 象 (接收 者 角色 ) 、 执 行 行为 (命令 角色 ) ， 
让 两 者 相互 独立 而 不 相互 影响 。 


我 们 从 一 个 相同 的 业务 需求 出 发 ， 按 照 命令 模式 和 策略 模式 分 别 
设计 出 一 父 实 现 ， 来 看 看 它们 的 侧重 点 有 什么 不 同 。zip 和 gzip 文 件 格 
式 相信 大 家 都 很 熟悉 ， 它 们 是 两 种 不 同 的 压缩 格式 ， 我 们 今天 就 来 对 
一 个 目 永 或 文件 实现 两 种 不 同 的 压缩 方式 : zip 压 缩 和 gzip 讨 缩 (这 里 
的 压缩 指 的 是 压缩 和 解压 缩 两 种 对 应 的 操作 行为 ， 下 同 ) 。 实 现 这 两 
种 压缩 格式 有 什么 意义 呢 ? 有 意义 ! 一 是 zip 格 式 (.zip 后 缀 ) 是 
Windows 操 作 系统 第 用 的 压缩 格式 ，gzip 格 式 .gz 后 缀 ) 是 *nix 系 统 常 
用 的 压缩 格式 ， 二 是 JDK 提 供 了 对 zip 和 gzip 文 件 的 操作 包 ， 非 常 容 易 实 
现 文 件 的 压缩 和 解压 缩 操作 。 


下 面 我 们 来 实现 不 同 格式 的 压缩 和 解压 缩 功 能 。 


32.1.1 策略 模式 实现 压缩 算法 


使 用 策略 模式 实现 压缩 算法 非常 简单 ， 也 是 非常 标准 的 ， 类 图 如 
图 32-1 所 示 。 


在 类 图 中 ， 我 们 的 侧重 点 是 zip 压 缩 算 法 和 gzip 压 缩 算法 可 以 互相 
替换 ， 一 个 文件 或 者 目录 可 以 使 用 zip 压 缩 ， 也 可 以 使 用 gzip 压 缩 ， 选 
择 哪 种 压缩 算法 是 由 高 层 模块 (实际 操作 者 ) 决定 的 。 我 们 来 看 一 下 
代码 实现 。 先 看 抽象 的 压缩 算法 ， 如 代码 清单 32-1 所 示 。 


| 


<<interface>> 


Context Algorithm 
| 
+boolean compress(String source, String to) +boolean compress(String source, String to) 
+boolean uncompress(String source, String to) +boolean uncompress(String source, String to) 


Gzip 
| 
[| 。= | 


zip 压 缩 算 法 、 


图 32-1 寅 略 模 式 实 现 压 缩 算 法 的 类 图 


代码 清单 32-1 抽象 压缩 算法 


public interface Algorithm { 
// 压 缩 算 法 


public boolean compress(String source,String to); 


// 解 压缩 算法 


public boolean uncompress(String source,String to); 


每 一 个 算法 要 实现 两 个 功能 : 压缩 和 解压 缩 ， 传 递 进 来 一 个 绝对 
路 径 source，compress 把 它 压 缩 到 to 目录 下 ，uncompress 则 进行 反 回 操 
作 一 一 解压 缩 ， 这 两 个 方法 一 定 要 成 对 地 实现 ， 为 什么 呢 ? 用 gzip 解 压 
缩 算 法 能 解 开 zip 格 式 的 压缩 文件 吗 ? 我 们 分 别 来 看 两 种 不 同 格式 的 压 
缩 算法 ，zip、gzip 压 缩 算 法 分 别 如 代码 清单 32-2、 代 码 清单 32-3 所 示 。 


代码 清单 32-2 zip 压 缩 算法 


public class Zip implements Algorithm { 


//zip 格 式 的 压缩 算法 
public boolean compress(String source, String to) { 
System,.out.println(source + " -->" +to + " ZIP 压 缩 
成 功 !1"); 


return true; 


} 
//zip 格 式 的 解压 缩 算 法 
public boolean uncompress(String source,String to){ 
System.out.println(source + " -->" +to + " ZIP 解 压 
缩 成 功 1"); 


} 


return true; 


代码 清单 32-3 gzip 压 缩 算 法 


public class Gzip implements Algorithm { 


//gzip 的 压缩 算法 
public boolean compress(String source, String to) { 
System,out,.println(source + " -->" +to + " GZIP 上 压缩 
成 功 !1"); 


return true; 


; 
//gzip 解 压缩 算法 


public boolean uncompress(String source,String to){ 
System.out.println(source + " --> " +to + " GZIP 解 压 
缩 成 功 !" ) ; 


于 


return true; 


这 两 种 压缩 算法 实现 起 来 部 很 创 单 ，Java 对 此 都 提供 了 相关 的 API 
操作 ， 这 里 束 不 再 提供 详细 的 编写 代码 ， 读 着 可 以 参考 JDK 目 己 进行 实 
现 ， 或 者 上 网 搜索 一 下 ， 网 上 有 太 多 类 似 的 源 代码 。 


两 个 具体 的 算法 实现 了 同一 个 接口 ， 完 全 遵循 依赖 倒转 原则 。 我 
们 再 来 看 环境 角色 ， 如 代码 清单 32-4 所 示 。 


代码 清单 32-4 环境 角色 


public class Context { 

// 指 向 抽象 算 》 

private Algorithm al; 

// 构 造 函 数 传 递 具体 的 算法 

public Context(Algorithm _al)t{ 
this.al = _al; 


} 

// 执 行 压缩 算法 

public boolean compress(String source,String to)t{ 
return al.compress(source, to); 


} 

// 执 行 解压 缩 算法 

public boolean uncompress(String source,String to){ 
return al.uncompress(source, to); 

} 


也 是 非常 答 单 ， 指 定 一 个 算法 ， 执 行 该 算法 ， 一 个 标准 的 策略 模 
式 就 编写 完毕 了 。 请 读者 注意 ， 这 里 虽然 有 两 个 算法 Zip 和 Gzip， 但 是 
对 调用 者 来 说 ， 这 两 个 算法 没有 本 质 上 的 区 别 ， 只 是 “形式 ”上 不 同 ， 


什么 意思 呢 ? 从 调用 者 来 看 ， 使 用 哪 一 个 算法 都 无 所 谓 ， 两 者 完全 可 
以 互 换 ， 甚 至 用 一 个 算法 奉 代 另外 一 个 算法 。 我 们 继续 看 调用 者 下 如 
何 调用 的 ， 如 代码 清单 32-5 所 示 。 


代码 清单 32-5 场景 


public class Client { 
public static void main(String[] args) { 
// 定 义 环境 角色 
Context context ， 


// 对 文件 执行 zip 压 缩 算法 


System.out.printlLn("======== 执 行 算法 ========") 
context = new Context(new Zip()); 
* 算 法 替换 
* Context = new Context(new Gzip()); 
A 
// 执 行 压缩 算法 
context.compress("c:\\windows","d:\\windows.zip"); 
// 执 行 解 压缩 算法 
context ,uncompress("c:NAwindows ,zip"，"d:NXNXwindows”") ; 
} 
} 
运行 结果 如 下 所 示 : 


c:\windows --> d:\windows.zip ZIP 压缩 成 功 ! 


cvwindows.zip --> dvwindows ZIP 解压 缩 成 功 ! 


要 使 用 gzip 算 法 吗 ? 在 客户 端 (Client) 上 把 注释 删 掉 就 可 以 了 ， 
其 他 的 模块 根本 不 受 任 何 影响 ， 策 略 模式 关心 的 是 算法 是 否 可 以 相互 


丛 换 。 寅 略 模式 虽然 简单 ， 但 是 在 项 目 组 使 用 得 非 钊 多 ， 可 以 说 随手 
拓 来 束 是 一 个 策略 模式 。 


32.1.2 命令 模式 实现 压缩 算法 


命令 模式 的 主 下 是 封装 命令 ， 使 请 求 者 与 实现 者 解 稍 。 例 如 ， 到 
饭店 点 沫 ， 客 人 《请求 者 ) 通过 服务 员 (调用 者 ) 向 厨师 (接收 者 ) 
发 送 了 订单 (行为 的 请 求 ) ， 该 例子 就 是 通过 封装 命令 来 使 请 求 者 和 
接收 着 解 厢 。 我 们 继续 来 看 压缩 和 解压 缩 的 例子 ， 怎 么 使 用 命令 模式 
来 完成 该 需求 呢 ? 我 们 先 画 出 类 图 ， 如 图 32-2 所 示 。 


类 图 看 着 复杂 ， 但 是 还 是 一 个 典型 的 命令 模式 ， 通 过 定义 具体 命 
令 完 成 文件 的 压缩 、 解 压缩 任务 ， 注 意 我 们 这 里 对 文件 的 每 一 个 操作 
都 是 封装 好 的 命令 ， 对 于 给 定 的 请 求 ， 命 令 不 同 ， 处 理 的 结果 当然 也 
不 同 ， 这 就 是 命令 模式 要 强调 的 。 我 们 先 来 看 抽象 命令 ， 如 代码 清单 
32-6 所 示 。 


代码 清单 32-6 抽象 压缩 命令 


public abstract class AbstractCmd { 
// 对 接收 者 的 引用 
protected IReceiver zip = new ZipReceiver(); 
protected IReceiver gzip = new GzipReceiver(); 
// 抽 象 方法 ， 命 令 的 具体 单元 
public abstract boolean execute(String source,String to); 


<<imterface>> 
IReceiver 


[| #IReceiver zip = new ZipRece1ver() 
#IReceiver gzip = new GzipReceiver() 


ZipCompressCmd 


图 32-2 命令 模式 实现 压缩 算法 的 类 图 


+boolean execute(String source, String to) 


ZipUncompressCmd| |GzipCompressCmd| |GzipUncompressCmd 


抽象 命令 定义 了 两 个 接收 者 的 引用 : zip 接 收 者 和 gzip 接 收 者 ， 大 
家 可 以 想象 一 下 这 两 个 “受气 包 ”， 它 们 完全 是 受众 ， 人 家 让 它 干 哈 它 
就 干 哈 ， 具 体 使 用 哪个 接收 者 是 命令 决定 的 。 具 体 命令 有 4 个 : zip 压 
缩 、zip 解 压缩 、gzip 压 缩 、gzip 解 压缩 ， 分 别 如 代码 清单 32-7、32-8、 


32-9、32-10 所 示 。 


代码 清单 32-7 zip 压 缩 命 令 


public class ZipCompressCmd extends AbstractCmd { 
public boolean execute(String source,String to) { 
return super.zip.compress(source, to); 
} 


代码 清单 32-8 zip 解 压缩 命令 


public class ZipUncompressCmd extends AbstractCmd { 
public boolean execute(String source,String to) { 
return super.zip.uncompress(source, to); 
} 


代码 清单 32-9 gzip 压 缩 命令 


public class GzipCompressCmd extends AbstractCcmd { 
public boolean execute(String source,String to) { 
return super.gzip.compress(source, to); 
} 


代码 清单 32-10 gzip 解 压缩 命令 


public class GzipUncompressCmd extends AbstractCmd { 
public boolean execute(String source,String to) { 
return super.gzip.uncompress(source, to); 
} 


它们 非常 简单 ， 都 只 有 一 个 方法 ， 坚 决 地 执行 命令 ， 使 用 了 委托 
的 方式 ， 由 接收 者 来 实现 。 我 们 再 来 看 抽象 接收 者 ， 如 代码 清单 32-11 
扩 示 


代码 清单 32-11 抽象 接收 者 


public interface IReceiver { 
// 压 缩 
public boolean compress(String source,String to); 
// 解 压缩 
public boolean uncompress(String source,String to); 


抽象 接收 者 与 策略 模式 的 抽象 策略 完全 相同 ， 具 体 的 实现 也 完全 
相同 ， 只 是 类 名 做 了 改动 ， 我 们 先 来 看 zip 压 缩 的 实现 ， 如 代码 清单 32- 


12 所 示 。 


代码 清单 32-12 zip 接 收 者 
public class ZipReceiver implements IReceiver { 
//Zip 格 式 的 压缩 算法 
public boolean compress(String source, String to) { 
System.out.println(source + " --> " +to + " ZIP 压 缩 
成 功 !1"); 


return true; 
} 
//zip 格 式 的 解压 缩 算 法 


public boolean uncompress(String source,String to){ 
System.out.println(source + " --> " +to + " ZIP 解 压 
缩 成 功 !" ) ; 


} 


return true; 


这 束 是 一 个 具体 动作 执行 者 ， 它 在 策略 模式 中 是 一 个 具体 的 算 
法 ， 天 心 的 是 是 否 可 以 被 蔡 换 ， 而 在 命令 模式 中 ， 它 则 是 一 个 具体 、 
真实 的 命令 执行 者 。 我 们 再 来 看 gzip 接 收 者 ， 如 代码 清单 32-13 所 示 。 


代码 清单 32-13 gzip 接 收 者 


public class GzipReceiver implements IReceiver { 


//gzip 的 压缩 算法 
public boolean compress(String source, String to) { 
System.out.println(source + " --> " +to + " GZIP 压 缩 
成 功 !1")， 
return true; 
} 
//gzip 解 压缩 算法 
public boolean uncompress(String source,String to){ 
System.out.println(source + " --> " +to + " GZIP 解 压 
缩 成 功 !" ) ; 


return true; 


} 


大 家 可 以 这 样 思考 这 个 问题 ， 接 收 者 可 是 厨房 的 厨师 ， 具 体 妥 哪 
个 厨师 做 这 道 雪 则 征 餐 饶 的 规章 制度 已 经 明确 的 ， 你 让 专 做 粤菜 的 师 
传 做 一 个 币 概 鱼 头 ， 能 做 出 好 沫 吗 ? 在 命令 模式 中 ， 束 是 在 抽象 命令 
中 定义 了 接收 着 的 引用 ， 然 后 在 具体 的 实现 类 中 确定 要 让 哪个 接收 着 


进行 处 理 。 这 就 好 比 是 客人 点 菜 : 我 要 一 个 市 椒 鱼 涉 ， 这 就 是 一 个 命 
令 ， 然 后 服务 员 (Inovker) 接收 到 这 个 命令 后 ， 就 开始 执行 ， 把 这 个 
命令 指定 给 具体 的 执行 者 执行 。 


当然 了 ， 接 收 者 这 部 分 还 可 以 这 样 设计 ， 即 按照 职责 设计 接收 
者 ， 比 如 压缩 接收 者 、 解 压缩 接收 者 ， 但 接口 需要 稍稍 改动 ， 如 代码 
清单 32-14 所 示 。 


代码 清单 32-14 依照 职责 设计 的 接收 着 接口 


public interface IReceiver { 

// 执 行 zip 命 令 

public boolean zipExec(String source,String to); 

// 执 行 gzip 命 令 

public boolean gzipExec(String source,String to); 

接收 者 接口 只 是 定义 了 每 个 接收 者 都 必须 完成 ztp 和 gzip 相 关 的 两 
个 逻辑 ， 有 多 少 个 职责 就 有 多 少 个 实现 类 。 我 们 这 里 只 有 两 个 职责 : 
压缩 和 解压 缩 ， 分 别 如 代码 清单 32-15、32-16 所 示 。 


代码 清单 32-15 压缩 接收 者 


public class CompressReceiver implements IReceiver { 
// 执 行 gzip 压 缩 命令 


public boolean gzipExec(String source, String to) { 
System,.out.println(source + " -->" +to + " GZIP 压 缩 
成 功 !1")， 


return true; 
} 
// 执 行 zip 压 缩 命 令 


public boolean zipExec(String source, String to) { 
System.out.println(source + " --> " +to + " ZIP 压 缩 
成 功 ! " ) ; 


return true; 


代码 清单 32-16 解压 缩 接收 者 


public class UncompressReceiver implements IReceiver { 
// 执 行 gzip 解 压缩 命令 
public boolean gzipExec(String source, String to) { 
System.out.println(source + " --> " +to + " GZIP 解 压 
缩 成 功 !1")， 


return true; 
} 
// 执 行 zip 解 压缩 命令 


public boolean zipExec(String source, String to) { 
System.out.println(source + " --> " +to + " ZIP 解 压 
缩 成 功 !" ) ; 


了 


return true; 


剩 下 的 工作 就 是 对 抽象 命令 、 具 体 命令 稍 作 修改 ， 这 里 不 再 费 
述 。 为 什么 要 在 这 里 增加 一 个 分 文 朱 述 呢 ? 这 是 为 了 与 抹 略 模式 对 
比 ， 在 命令 模式 中 ， 我 们 可 以 把 接收 着 设计 得 与 策略 模式 的 算计 相 
同 ， 也 可 以 不 相同 。 我 们 按照 职责 设计 的 接口 就 不 适用 于 策略 模式 ， 
可 能 封装 一 个 叫做 压缩 的 算法 类 ， 然 后 在 类 中 提供 两 种 不 同 格式 的 
压缩 功能 ， 这 违背 了 策略 模式 的 意 封 痛 算法 ， 为 什么 呢 ? 如 采 
要 增加 一 个 rar 压 缩 算法 ， 该 怎么 办 呢 ? 修改 抽象 算法 ? 这 是 绝对 不 多 


| 


许 的 ! 那 为 什么 命令 模式 就 是 允许 的 呢 ? 因为 命令 模式 着 重 于 请 求 者 
和 接收 着 解 粳 ， 你 管 我 接收 半 怎 么 变化 ， 只 要 不 影响 请 求 着 就 成 ， 这 
才 是 命令 模式 的 意图 。 


命令 、 接 收 者 都 具备 了 ， 我 们 再 来 封装 一 个 命令 的 调用 者 ， 如 代 
码 清 单 32-17 所 示 。 


代码 清单 32-17 调用 者 


public class Invoker { 
// 抽 象 命令 的 引用 
private AbstractCcmd cmd ; 
public Invoker(AbstractCcmd _cmd){ 
this.cmd = _cmd; 


} 

// 执 行 命令 

public boolean execute(String source,String to)t{ 
return cmd.execute(source, to0o); 

} 


调用 者 非 营 简单， 只 负责 把 命令 癌 后 传递 ， 当 然 这 里 也 可 以 进行 
一 定 的 拦截 处 理 ， 我 们 暂时 用 不 到 惑 不 做 处 理 了 。 我 们 来 看 场景 类 旦 
如 何 插 述 这 个 场景 的 ， 如 代码 清单 32-18 所 示 。 


代码 清单 32-18 场景 > 


public class Client { 
public static void main(String[] args) { 
// 定 义 一 个 命令 ,压缩 一 个 文件 
Abstractcmd cmd = new ZipCcompressCcmd ( ) ， 


* 想 换 一 个 ? 执行 解压 命令 
* AbstractCmd cmd = new ZipUncompressCmd(); 
*/ 


// 定 义 调用 者 

Invoker invoker = new Invoker(cmd ) ; 

// 我 命令 你 对 这 个 文件 进行 压缩 
System.out.println("======== 执 行 压缩 命令 ========" )， 
invoker .execute("c:\\windows", "d:\\windows.zip"); 


证 


想 新 增 一 个 命令 ? 当然 没有 问题 ， 只 要 重新 定义 一 个 命令 束 成 ， 
命令 改变 了 ， 高 层 模块 只 要 调用 它 就 成 。 请 注意 ， 这 里 的 程序 还 有 点 
闪 缺 ， 没 有 与 文件 的 后 缀 名 绑 定 ， 不 应 该 出 现 使 用 zip 压 纵 命 令 产生 一 
个 .gzip 后 缀 的 文件 名 ， 读 者 在 实际 应 用 中 可 以 考虑 与 文件 后 绥 名 之 间 
建立 关联 。 


通过 以 上 例子 ， 我 们 看 到 命令 模式 也 实现 了 文件 的 压缩 、 解 压缩 
的 功能 ， 它 的 实现 是 天 注 了 命令 的 封 流 ， 是 请 求 者 与 执行 者 彻 改 分 
开 ， 看 看 我 们 的 程序 ， 执 行者 根本 就 不 用 了 解 命令 的 具体 执行 者 ， 它 
只 要 封 痛 一 个 命令 一 一 “给 我 用 zip 格 式 庄 缩 这 个 文件 ? 束 可 以 了 ， 具 体 
由 谁 来 执行 ， 则 由 调用 者 负责 ， 如 此 设计 后 ， 就 可 以 保证 请 求 者 和 执 
行者 之 间 可 以 相互 独立 ， 各 上 自 发展 而 不 相互 影响 。 


同时 ， 由 于 是 一 个 命令 模式 ， 接 收 着 的 处 理 可 以 进行 排队 处 理 ， 
在 排队 处 理 的 过 程 中 ， 可 以 进行 撤销 处 理 ， 比 如 客人 点 了 一 个 末 ， 厨 
师 还 没 来 得 及 做 ， 那 要 撤回 很 简单 ， 撤 回 也 是 命令 ， 这 走 策 略 模式 所 
不 能 实现 的 。 


3 让 续 


策略 模式 和 命令 模式 相似 ， 特 别 是 命令 模式 退化 时 ， 比 如 无 接收 
者 〈 接 收 者 非常 简单 或 者 接收 者 是 一 个 Java 的 基础 操作 ， 无 需 专门 编写 
一 个 接收 者 ， 在 这 种 情况 下 ， 命 令 模式 和 策略 模式 的 类 图 完全 一 
样 ， 代 码 实 现 也 比较 类 似 ， 但 是 两 着 还 是 有 区 别 的 。 


e 大 注 反 不 同 


策略 模式 关注 的 是 算法 蔡 换 的 问题 ， 一 个 新 的 算法 投产 ， 旧 算法 
退休 ， 或 者 提供 多 种 算法 由 调用 着 目 己 选 择 使 用 ， 算 法 的 目 由 更 蔡 是 
它 实 现 的 要 上 后。 换 句 话说 ， 筑 略 模式 关注 的 是 算法 的 完整 性 、 封 疤 
性 ， 只 有 具备 了 这 两 个 条 件 才 能 保证 其 可 以 目 由 切换 。 


命令 模式 则 关注 的 是 解 耦 问题 ， 如 何 让 请 求 者 和 执行 者 解 簿 是 它 
需要 首先 解决 的 ， 解 耦 的 要 求 就 是 把 请 求 的 内 容 封装 为 一 个 一 个 的 命 
令 ， 由 接收 者 执行 。 由 于 封装 成 了 命令 ， 了 就 同时 可 以 对 命令 进行 多 种 
处 理 ， 例 如 撤销 、 记 杂 等 。 


e 角色 功能 不 同 


在 我 们 的 例子 中 ， 策 略 模式 中 的 抽象 算法 和 具体 算法 与 命令 模式 
的 接收 阁 非 常 相似 ， 但 是 它们 的 职员 不同。 策略 模式 中 的 具体 算法 是 
人 负责 一 个 完整 算法 逻辑 ， 它 十 不 可 再 拆 分 的 原子 业务 单元 ,一旦 变更 
束 古 对 算法 整体 的 变更 。 


而 命令 模式 则 不 同 ， 它 关注 命令 的 实现 ， 也 束 是 功能 的 实现 。 例 
如 我 们 在 分 文中 也 近 到 接收 着 的 变更 问题 ， 它 只 影响 到 命令 族 的 变 
更 ， 对 请 求 郑 没有 任何 影响 ， 从 这 方面 来 说 ， 接 收 着 对 命令 负责 ， 而 
与 请 求 者 无 天 。 命 令 模 式 中 的 接收 着 只 要 符合 六 大 设计 原则 ， 完 全 不 
用 关心 它 是 否 完 成 了 一 个 具体 逻辑 ， 它 的 影响 范围 也 仅仅 是 抽象 命令 
和 具体 命令 ， 对 它 的 修改 不 会 扩散 到 模式 外 的 模块 。 


当然 ， 如 采 在 命令 模式 中 需要 指定 接收 者 ， 则 需要 考虑 接收 者 的 
变化 和 封装 ， 例 如 一 个 老 顾 客 每 次 吃 氏 都 点 同一 个 厨师 的 饭菜 ， 那 束 
必须 考虑 接收 者 的 抽象 化 问题 。 


e 使 用 场景 不 同 


策略 模式 适用 于 算法 要 求 变 换 的 场景 ， 而 命令 模式 适用 于 解 硝 两 
个 有 紧 类 合 关 系 的 对 象 场合 或 者 多 命令 多 撤销 的 场景 。 


32.2 策略 模式 VS 状态 模式 


在 行为 类 设计 模式 中 ， 状 态 模 式 和 策略 模式 是 亲 兄 第 ， 两 着 非 党 
相似 ， 我 们 先 看 看 两 者 的 通用 类 图 ， 把 两 者 放 在 一 起 比较 一 下 ， 如 图 


32-3 所 示 。 
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图 32-3 策略 模式 ( 左 ) 和 状态 模式 ( 右 ) 的 通用 类 图 


两 个 类 图 非常 相似 ， 都 是 通过 Context 类 封装 一 个 具体 的 行为 ， 都 
提供 了 一 个 封装 的 方法 ， 是 高 扩展 性 的 设计 模式 。 但 根据 两 者 的 定 
义 ， 我 们 发 现 两 着 的 区 别 还 是 很 明显 的 ， 策略 模式 封 汉 的 是 不 同 的 算 
法 ， 算 法 之 间 没 有 交互 ， 以 达到 算法 可 以 目 由 切换 的 目的 ;而 状态 模 
式 封 泛 的 是 不 同 的 状态 ， 以 达到 状态 切换 行为 随 之 发 生 改变 的 目的 。 
这 两 种 模式 虽然 部 有 变换 的 行为 ， 但 是 两 着 的 目标 却 古 不 同 的 。 我 们 
举例 来 说 明 两 着 的 不 同 点 。 


人 只 要 生 下 来 束 有 工作 可 做 ， 人 在 孩 鞋 时 期 的 主要 工作 束 是 玩 要 
(学 习 只 是 在 人 类 具有 了 精神 意识 行为 后 才 产 生 的) ; 成 人 时 期 的 主 
要 工作 是 养活 自己 ， 然 后 为 社会 做 贡献 ， 老 年 时 期 的 主要 工作 就 是 译 


受 天 伦 之 乐 。 按 照 策略 模式 来 分 析 ， 这 三 种 不 同 的 工作 方式 束 是 三 个 
不 同 的 具体 算法 ， 随 看 时 光 的 推移 工作 内 容 随 之 更 耕 ， 这 和 对 一 堆 数 
组 的 冒 泡 排 序 、 快 速 排序 、 捅 入 排序 一 样 ， 都 吓 一 系列 的 算法 ， 而 按 
照 状 态 模式 进行 设计 ， 则 认为 人 的 状态 ( 孩 鞋 、 成 人 、 老 人 ) 产生 了 
不 同 的 行为 结 有 末 ， 这 里 的 行为 都 相同 ， 都 是 工作 ， 但 是 它们 的 实现 方 
式 确实 不 同 ， 也 融 是 产生 的 结 东 不同 ， 看 起 来 吏 像 征 类 改变 了 。 


32.2.1 策略 模式 实现 人 生 


下 面 按 照 集 略 模 式 进 行 设计 ， 先 来 看 类 图 ， 如 图 32-4 所 示 。 


这 是 非常 典型 的 策略 模式 ， 没 有 太 多 的 芯 机 ， 它 定义 了 一 个 工作 
算法 ， 然 后 有 三 个 实现 类 : 孩童 工作 、 成 年 人 工作 和 老年 人 工作 。 我 
们 来 看 代码 ， 百 先 看 抽象 工作 算法 ， 如 代码 清单 32-19 所 示 。 


WorkAlgorithm 
| 


| 
-一 一 +void work() 


ChildWork OldWork 


AdultWork 
| 
| | 


图 32-4 朱 略 模式 实现 人 生 的 类 图 


代码 清单 32-19 抽象 工作 算法 


public abstract class WorkAlgorithm { 
// 每 个 年 龄 段 都 必须 完成 的 工作 
public abstract void work(); 


无 论 如 何 ， 每 个 算法 都 必须 实现 work 方 法 ， 完 成 对 工作 内 容 的 定 
义 ， 三 个 具体 的 工作 算法 如 代码 清单 32-20、32-21、32-22 所 示 。 


代码 清单 32-20 孩童 工作 


public class Childwork extends WorkAlgorithm { 
// 小 孩 的 工作 
@Override 
public void work() { 
System.out.println(" 儿 和 鞋 的 工作 是 玩 页 !"); 


} 
代码 清单 32-21 成 年 人 工作 
public class Adultwork extends WorkAlgorithm { 
// 成 年 人 的 工作 
@Override 


public void work() { 


System.out.println(" 成 年 人 的 工作 就 是 先 养 活 自 己 ， 然 后 为 * 
会 做 贡献! "); 
} 


代码 清单 32-22 老年 人 工作 


public class Oldwork extends WorkAlgorithm { 
// 老 年 人 的 工作 


Q@Override 


public void work() { 
System.out .println(" 老 年 人 的 工作 就 是 享受 天 伦 之 乐 ! ") 
} 


我 们 再 来 看 环境 角色 ， 如 代码 清单 32-23 所 示 。 


代码 清单 32-23 环境 角色 


public class Context { 
private WorkAlgorithm workMethod; 
public WorkAlgorithm getwork() { 
return workMethod; 


} 
public void setwWork(WorkAlgorithm work) { 
this.workMethod = work; 


} 

// 每 个 算法 都 有 必须 具有 的 功能 

public void work()t{ 
workMethod .work(); 

} 


我 们 编写 一 个 场景 类 来 模拟 该 场景 ， 如 代码 清单 32-24 所 示 。 


代码 清单 32-24 场景 > 


public class Client { 

public static void main(String[] args) { 
// 定 义 一 个 环境 角色 
Context context=new Context(); 
System,.out .println("==== 儿 童 的 主要 工作 =====" )，} 
context.setwork(new Childwork()); 
context .work( ); 
System.out.println("\n==== 成 年 人 的 主要 工作 =====")， 
context.setwork(new Adultwork( )); 
context .work( ); 
System.out.println("\n==== 老 年 人 的 主要 工作 =====")， 
context.setwork(new Oldwork()); 
context .work( ); 


在 这 里 我 们 把 每 个 不 同 的 工作 内 容 作为 不 同 的 算法 ， 分 别 是 孩童 
工作 、 成 年 人 工作 、 老 年 人 工作 算法 ， 然 后 在 场景 类 中 根据 不 同 的 年 
龄 段 匹配 不 同 的 工作 内 容 ， 其 运行 结 末 如 下 所 示 : 


-=== 儿 童 的 主要 工作 =-==-= 


儿 鞋 的 工作 是 玩 要 ! 


==== 成 年 人 的 主要 工作 ===== 


成 年 人 的 工作 就 是 移 养 活 自己 ， 然 后 为 社会 做 贡献 


==== 考 年 人 的 主要 工作 ===== 


老年 人 的 工作 束 是 至 受 天 伦 之 乐 ! 


通过 采用 筑 略 模式 我 们 实现 了 “工作 ”这 个 策略 的 三 种 不 同 算法 ， 
算法 可 以 自由 切换 ， 到 底 用 哪个 算法 由 调用 者 (高 层 模块 ) 决 是。 入 
格 模 式 的 使 用 重点 是 算法 的 目 由 切换 一 老 的 算法 退休 ， 者 的 算法 上 
台 ， 对 模块 的 整体 功能 没有 非常 大 的 改变 ， 非 党 灵活 。 而 如 果 想 要 增 
加 一 个 新 的 算法 ， 比 如 未 出 生 婴 儿 的 工作 ， 只 要 继承 WorkAlgorithm 束 
可 以 了 。 


32.2.2 状态 模式 实现 人 生 


我 们 再 来 看 看 使 用 状态 模式 是 如 何 实现 该 需求 的 。 随 着 时 间 的 变 
化 ， 人 的 状态 变化 了 ， 同 时 引起 了 人 的 工作 行为 改变 ， 完 全 符合 状态 
模式 。 我 们 来 看 类 图 ， 如 图 32-5 所 示 。 


+setState(HumanState state) 
+void work() 
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HumanState 
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+void work!) 
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图 32-5 状态 模式 实现 人 生 的 类 图 


这 与 策略 模式 非常 相似 ， 基 本 上 就 是 几 个 类 名 称 的 修改 而 已 ， 但 
是 其 中 组 藏 的 玄机 就 大 了 ， 看 看 代码 你 束 会 明日 。 我 们 先 来 看 抽象 状 
仿 类 ， 如 代码 清单 32-25 所 示 。 


代码 清单 32-25 人 的 抽象 状态 


public abstract class HumanState { 
// 指 向 一 个 具体 的 人 


protected Human human 

// 设 置 一 个 具体 的 人 

public void setHuman(Human _human)t{ 
this.human = _human， 


} 
// 不 管 人 是 什么 状态 都 要 工作 


public abstract void work(); 


抽象 状态 定义 了 一 个 具体 的 人 (human) 必须 进行 工作 (work) ， 
但 是 一 个 人 在 哪些 状态 下 完成 哪些 工作 则 是 由 子 类 来 实现 的 。 我 们 先 
来 看 孩 董 状态 ， 如 代码 清单 32-26 所 示 。 


代码 清单 32-26 孩童 状态 


public class ChildState extends HumanStatet 
// 儿 童 的 工作 就 是 玩 要 
public void work(){ 
System.out.printlLn(" 儿 童 的 工作 是 玩 灰 ! ") ; 
Super .human.setState(Human.ADULT_STATE); 


ChildState 类 代表 孩童 状态 ， 在 该 状态 下 的 工作 就 是 玩 机 。 读 者 看 
着 可 能 有 点 惊奇 ， 在 work 方 法 中 为 什么 要 设置 下 一 个 状态 ? 因为 我 们 
的 状态 变化 都 是 单方 向 的 ， 从 孩童 到 成 年 人 ， 然 后 到 老年 人 ， 每 个 状 
态 转 换 到 其 他 状态 只 有 一 个 方向 ， 因 此 会 在 这 里 看 到 work 有 两 个 职 
责 : 完成 工作 逻辑 和 定义 下 一 状态 。 


我 们 再 来 看 成 年 人 状态 和 老年 人 状态 ， 分 别 如 代码 清单 32-27、32- 
28 所 示 。 


代码 清单 32-27 成 年 人 状态 


public class AdultState extends HumanState { 
// 成 年 人 的 工作 就 是 先 养活 自己， 然后 为 社会 做 贡献 
Q@Override 
public void work() { 
System,out,.println(" 成 年 人 的 工作 就 是 先 养活 自己 ， 然 后 为 
会 做 贡献 ! ") ; 
Super .human,setState(Human.OLD_STATE ) ; 
} 


代码 清单 32-28 老年 人 状态 


public class OldState extends HumanState { 
// 老 年 人 的 工作 就 是 享受 天 伦 之 乐 
@Override 
public void work() { 
System.out .println(" 老 年 人 的 工作 就 是 享受 天 伦 之 乐 !"); 
} 


每 一 个 HumanState 的 子 类 都 代表 了 一 种 状态 ,虽然 实现 的 方法 名 
work 都 相同 ， 但 是 实现 的 内 容 却 不 同 ， 也 就 是 在 不 同 的 状态 下 行为 随 
之 改变 。 我 们 来 看 环境 角色 是 如 何 处 理 行为 随 状态 的 改变 而 改变 的 ， 
如 代码 清单 32-29 所 示 。 


代码 清单 32-29 环境 角色 


public class Human { 

// 定 义 人 类 都 具备 哪些 状态 

public static final HumanState CHIILD_STATE = new 
childstate( ); 

public static final HumanState ADULT_STATE = new 
AdultState( ); 

public static final HumanState OLD_STATE = new OldState(); 

// 定 义 一 个 人 的 状态 

private HumanState state; 


// 设 置 一 个 状态 
public void setState(HumanState _State){ 


this.state = _state,; 
this.state.setHuman(this); 
} 
// 人 类 的 工作 


public void work(){ 
this.state.work(); 
} 


定义 一 个 Human 类 代表 人 类 ， 也 就 十 状态 模式 中 的 环境 和 角色， 
个 人 都 会 经 历 从 孩童 到 成 年 人 再 到 老年 人 这 样 一 个 状态 过 渡 (当然 
了 ,， 老 顽童 周伯通 的 情况 我 们 就 没有 考虑 进来 ) ， 随 着 状态 的 改变 
行为 也 改变 。 我 们 来 看 场景 类 ， 如 代码 清单 32-30 所 示 。 


代码 清单 32-30 场景 


public class Client { 

public static void main(String[] args) { 
// 定 义 一 个 普通 的 人 
Human human = new Human( ) ; 
// 设 置 一 个 人 的 初始 状态 
human.setState(new ChildState( )); 
System,out .println("==== 儿 童 的 主要 工作 =====" )，} 
human .work(); 
System,.out .printlin("\n==== 成 年 人 的 主要 工作 =====")，; 
human .work(); 
System.out.println("\n==== 老 年 人 的 主要 工作 =====")， 
human .work(); 


运行 结果 如 下 所 示 : 


==== 儿 童 的 主要 工作 ===== 


儿 董 的 工作 是 玩 要 ! 


==== 成 年 人 的 主要 工作 ===== 


成 年 人 的 工作 就 是 移 养 活 自己 ， 然 后 为 社会 做 贡献 ! 


==== 老 年 人 的 主要 工作 ===== 


老年 人 的 工作 就 是 享受 天 伦 之 乐 ! 


运行 结果 与 策略 模式 相同 ， 但 是 两 者 的 分 析 角 度 是 大 相 径 许 的。 
策略 模式 的 实现 是 通过 分 析 每 个 人 的 工作 方式 的 不 同 而 得 出 三 个 不 同 
的 算法 人 逻辑， 状态 模式 则 是 从 人 的 生长 规律 来 分 析 ， 每 个 状态 对 应 了 
不 同 的 行为 ， 状 态 改变 后 行为 也 随 之 改变 。 从 以 上 示例 中 我 们 也 可 以 
看 出 ， 对 于 相同 的 业务 需求 ， 有 很 多 种 实现 方法 ， 问 题 的 重点 是 业务 
关注 的 是 什么 ， 是 人 的 生长 规律 还 是 工作 逻辑 ? 找 准 了 业务 的 焦点 ， 
才能 选择 一 个 好 的 设计 模式 。 


3 3 结 


从 例子 中 我 们 可 以 看 出 策略 模式 和 状态 模式 确实 非常 相似 ， 称 之 
为 杀 兄 第 亦 不 为 过 ， 但 是 这 两 者 还 是 存在 着 非 第 大 的 差别 ， 而 且 也 古 
很 容易 区 分 的 。 


e 环境 角色 的 职责 不 同 


两 痢 都 有 一 个 叫做 Context 环 境 角色 的 类 ， 但 是 两 兰 的 区 别 很 大 ， 
策略 模式 的 环境 角色 只 且 一 个 委托 作用 ， 负 责 算法 的 蔡 换 ， 而 状态 模 


式 的 环境 角色 不 仅仅 是 委托 行为 ， 它 还 具有 登记 状态 变化 的 功能 ， 与 
具体 的 状态 类 协作 ， 共 同 完成 状态 切换 行为 随 之 切换 的 任务 。 


e 解决 问题 的 重点 不 同 


策略 模式 旨 在 解决 内 部 算法 如 何 改 变 的 问题 ， 也 就 是 将 内 部 算法 
的 改变 对 外 界 的 影响 降低 到 最 小 ， 它 人 证 的 十 算 法 可 以 目 由 地 切换 ; 
而 状态 模式 让 在 解决 内 在 状态 的 改变 而 引起 行为 改变 的 问题 ， 它 的 出 
发 点 古事 物 的 状态 ， 封 装 状 态 而 其 露 行为 ， 一 个 对 象 的 状态 改变 ， 从 
外 界 来 看 就 好 像 是 行为 改变 。 


e 解决 问题 的 方法 不 同 


策略 模式 只 是 确保 算法 可 以 目 由 切换 ,但 是 什么 时 候 用 什么 算法 
它 决定 不 了 ; 而 状态 模式 对 外 暴露 的 是 行为 ， 状 态 的 变化 一 般 是 由 环 
境 角 色 和 具体 状态 共同 完成 的 ， 也 殊 是 说 状态 模式 封装 了 状态 的 变化 
而 其 露 了 不 同 的 行为 或 行为 结 琳 。 


e 应 用 场景 不 同 


两 者 都 能 实现 前 面 例子 中 的 场景 ， 但 并 不 表示 两 者 的 应 用 场景 相 
同 ， 这 只 是 为 了 更 好 地 展示 出 两 者 的 不 同 而 设计 的 一 个 场景 。 我 们 来 
想 一 下 宽 略 模式 和 状态 模式 的 使 用 场景 有 什么 不 同 ， 策 略 模式 只 坪 一 
个 算法 的 封装 ， 可 以 是 一 个 有 意义 的 对 象 ， 也 可 以 是 一 个 无 意义 的 逻 


辑 片 段 ， 比 如 MD5 加 密 算 法 ， 它 是 一 个 有 意义 的 对 象 吗 ? 不 是 ， 它 只 
是 我 们 数学 上 的 一 个 公式 的 相关 实现 ， 它 是 一 个 算法 ， 同 时 DES 算 

法 、RSA 算 法 等 都 是 具体 的 算法 ， 也 就 是 说 它们 都 是 一 个 抽象 算法 的 
具体 实现 类 ， 从 这 所 来 看 策略 模式 是 一 系列 平行 的 、 可 相互 车 换 的 算 
法 封 狠 后 的 结 末 ， 这 束 限 定 了 它 的 应 用 场景 ， 算 法 必须 是 平行 的 ， 否 
则 策略 模式 束 封 狐 了 一 堆 坪 圾 ， 产 生 了 “ 坏 味道 ”。 状态 模式 则 要 求 有 
一 系列 状态 发 生变 化 的 场景 ， 它 要 求 的 是 有 状态 且 有 行为 的 场景 ， 也 
就 是 一 个 对 象 必须 具有 二 维 (状态 和 行为 ) 描述 才能 采用 状态 模式 ， 
如 果 只 有 状态 而 没有 行为 ， 则 状态 的 变化 就 失去 了 意义 。 


e 复杂 度 不 同 


通 肖 策略 模式 比较 人 简单， 这 里 的 简单 指 的 是 结构 人 简单， 扩展 比较 
容易 ， 而 且 代 码 也 容易 阅读 。 当 然 ， 一 个 具体 的 算法 也 可 以 写 得 很 复 
杂 ， 只 有 具备 很 高 深 的 数学 、 物 理 等 知识 的 人 才 可 以 看 届 ， 这 也 是 允 
许 的 ， 我 们 只 是 说 从 设计 模式 的 角度 来 分 析 ， 它 是 很 容易 被 看 懂 的 。 
而 状态 模式 则 通常 比较 复杂 ， 因 为 它 要 从 两 个 角色 看 到 一 个 对 象 状态 
和 行为 的 改变 ， 也 融 是 说 它 封 于 的 是 变化 ， 要 知道 变化 生 无 穷尽 的 ， 
因此 相对 来 说 状态 模式 通 音 都 比较 复 洒 ， 涉 及 面 很 多 ， 虽 然 也 很 容易 
扩展 ， 但 是 一 般 不 会 进行 大 规模 的 扩张 和 修正 。 


32.3 观察 者 模式 VS 责任 链 模 式 


为 什么 要 把 观察 者 模式 和 责任 链 模 式 放 在 一 起 对 比 呢 ? 看 起 来 这 两 
个 模式 没有 太 多 的 相似 性 ， 真 没有 吗 ? 回答 是 有 。 我 们 在 观察 者 模式 中 
也 提 到 了 触发 链 (也 叫做 观察 者 链 ) 的 问题 ， 一 个 具体 的 角色 既 可 以 古 
观察 者 ， 也 可 以 古 补 观察 者 ， 这 样 束 形成 了 一 个 观察 者 链 。 这 与 责任 链 
模式 非常 类 似 ， 它 们 都 实现 了 事务 的 链条 化 处 理 ， 比 如 说 在 上 诬 的 时 候 
你 睡 着 了 ， 打 血 声 首 太 大 ， 盖 过 了 老师 讲课 声 首 ， 老 师 火 了 ， 捅 到 了 校 
长 这 里 ， 校 长 也 处 理 不 了 ， 然 后 告状 给 你 父母 ， 于 是 你 的 魔 罗 日 子 来 临 
了 ， 这 是 责任 链 模式 ， 老 师 、 校 长 、 父 母 都 是 链 中 的 一 个 具体 角色 ， 事 
件 《你 睡觉 ) 在 链 中 传递 ， 最 终 由 一 个 具体 的 节点 来 处 理 ， 并 将 结果 反 
馈 给 调用 者 (你 挨 接 了 ) 。 那 什么 是 触发 链 ? 你 还 是 在 课堂 上 睡觉 ， 还 
征 打 身 声音 太 大 ， 老 师 火 了 ， 但 是 老师 掏 出 个 扩 音 融 来 讲课 ， 于 十 你 睡 
不 着 了 ， 同 时 其 他 同学 的 耳 未 遭 浆 了 ， 这 台 是 触发 链 ， 其 中 老师 既是 观 
察 者 (相对 你 ) 也 是 被 观察 者 (相对 其 他 同学 ) ， 事 件 从 “你 睡觉 到 老 
师 这 里 转化 为 “ 扩 音 右 放 大 声 首 ”"， 这 也 是 一 个 链条 结构 ， 但 是 链 结构 中 
传递 的 事件 改变 了 。 


我 们 还 是 以 一 个 具体 的 例子 来 说 明 两 者 的 区 别 ，DNS 协 议 相 信 大 家 
都 听 说 过 ， 只 要 在 “网 络 设置 "中 设置 一 个 DNS 服 务 器 地 址 就 可 以 把 我 们 
需要 的 域名 翻译 成 I1P 地 址 。DNS 协 议 还 是 比较 简单 的 ， 传 递 过 去 一 个 域 


名 以 及 记录 标志 (比如 是 要 A 记录 还 是 要 MX 记录 ) ，DNS 就 开始 查找 自 
己 的 记录 树 ， 找 到 后 把 IP 地 址 反馈 给 请 求 者 。 我 们 可 以 在 Windows 操 作 
系统 中 了 解 一 下 DNS 解析 过 程 ， 在 DOS 窗 口 下 输入 nslookup 命 令 后 ， 结 
果 如 图 32-6 所 示 。 


192.168.10.1 
: 192.168.10.1 


INon-anithoritativye ansYWer: 
ame: XxXX.XXX.COM.Cn 
Address: 202.108.33.122 
iases: WwWW.XIIX.COILCD 


图 32-6 DNS 服 务 絮 解析 域名 


我 们 的 意图 就 是 要 DNS 服务 器 192.168.10.1 解 析出 www.xxx.com.cn 的 
IP 地 址 ，DNS 服 务 器 是 如 何 工作 的 呢 ? 图 32-6 中 的 192.168.10.1 这 个 DNS 
Server 存 储 着 全 球 的 域名 和 IP 之 间 的 对 应 关系 吗 ? 不 可 能 ， 目 前 全 球 的 
域名 数量 是 1.7 亿 个 ， 如 此 庞大 的 数字 ， 每 个 DNS 服务 器 都 存储 一 份 ， 还 
怎么 快速 响应 ? DNS 解析 的 响应 时 间 一 般 都 是 毫秒 级 别 的 ， 如 此 高 的 性 


EB 要 求 还 怎么 让 DNS 服 务 器 遍地 开 人 花呢? 而 且 域 名 变更 非常 频繁 ， 数 据 
读 写 的 量 也 非常 大 ， 不 可 能 每 个 DNS 服务 器 都 保留 这 1.7 亿 数据 ， 那 么 是 
皇 么 设计 的 呢 ? DNS 协议 还 是 很 聪明 的 ， 它 规定 了 每 个 区 域 的 DNS 服务 
器 (Local DNS) 只 保留 自己 区 域 的 域名 解析 ， 对 于 不 能 解析 的 域名 ， 
则 提交 上 级 域名 解析 右 解 析 ， 最 终 由 一 台 位 于 美国 洛杉矶 的 顶级 域名 服 
务 器 进行 解析 ， 返 回 结 琳 。 很 明显 这 有 古 一 个 事务 的 链 结构 处 理 ， 我 们 使 
用 两 种 模式 来 实现 该 解析 过 程 。 


IO 


32.3.1 责任 链 模 式 实 现 DNS 解 析 过 程 


本 小 节 我 们 用 责任 链 模 式 来 实现 DNS 解 析 过 程 。 首 先 我 们 定义 一 下 
业务 场景 ， 这 里 有 三 个 DNS 服务 器 : 上 海 DNS 服 务 器 (区 域 服务 器 ) 、 
中 国 顶 级 DNS 服 务 器 〈 父 服务 器 ) 、 全 球 顶 级 DNS 服务 器 ， 其 示意 图 如 
图 32-7 所 示 。 


上 海 DNS 中 国 顶级 DNS 全 球 顶 级 DNS 


图 32-7 DNS 解析 示意 图 


假设 有 请 求 者 发 出 请 求 ， 由 上 海 DNS 进 行 解析 ， 如 果 能 够 解析 ， 则 
返回 结果 ， 若 不 能 解析 ， 则 提交 给 父 服务 器 中国 顶 级 DNS) 进行 解 
析 ， 震 还 不 能 解析 ， 则 提交 到 全 球 顶 级 DNS 进行 解析 ， 知 还 不 能 解析 


呢 ? 那 束 返回 该 域名 无 法 解析 。 确 实 ， 这 与 贡 任 链 模式 非常 相似 ， 我 们 
把 这 一 过 程 抽 象 一 下 ， 类 图 如 图 32-8 所 示 。 


-DnsServer upperServer() 


+Recorder resolve(String domain) 
+setUpperServer(DnsServer upperServer) 
夫 oolea1m isLocal(String domain) 
#Recorder echo(String domain) 


Recorder 


-Strng domain 
S| -Strmg p 
-Strng owner 


| | 
[ee = 


+getter/setter() 


ChinaTopDnsServer 


SHDnsServer 
于 二 9 
EE = | 


图 32-8 责任 链 模 式 实 现 DNS 解 析 的 类 图 


我 们 来 解释 一 下 类 网，Recorder 是 一 个 BO 对 象 ， 它 记录 DNS 服务 多 
解析 后 的 结果 ， 包 括 域名 、 耳 地址 、 属 主 〈 即 由 谁 解析 的 ) ， 除 此 之 外 
还 有 getter/setter 方 法 。DnsServer 抽 象 类 中 的 resolve 方 法 是 一 个 基本 方 
法 ， 每 个 DNS 服务 器 都 必须 拥有 该 方法 ， 它 对 DNS 进行 解析 ， 如 何 解 析 
呢 ? 具体 是 由 echo 方 法 来 实现 的 ， 每 个 DNS 服务 硕 独 目 实现 。 类 图 还 是 
比较 简单 的 ， 我 们 首先 看 一 下 解析 记录 Recorder 类 ， 如 代码 清单 32-31 所 


修 ° 


代码 清单 32-31 解析 记录 


public class Recorder { 
// 域 名 
private String domain,; 
//IP 地 址 


private String ip; 


// 属 主 


private String owner ; 
public String getDomain() { 


} 
public 
} 
public 
} 
public 
} 
public 


} 
public 


return domain; 


void setDomain(String domain) { 


this.domain = domain; 


String getIp() { 
return ip; 


void setIp(String ip) { 


this.ip = ip; 


String getOwner() { 


return owner,; 


void setOwner(String owner) { 
this.owner = owner,; 


// 输 出 记录 信息 


Q@Override 
public String toString()t{ 


为 什么 要 和 履 写 toString 方 法 呢 ? 是 为 了 打印 展示 的 需 
Recorder 的 信息 打印 出 来 。 我 们 再 来 看 抽象 域名 服务 右 ， 


32 所 示 。 


String str= "域名 : 
str = str + "NXnIP 地 址 : 
解析 者 : 


str = Str + "\n 
return str,; 


代码 清单 32-32 抽象 域名 服务 器 


public abstract class DnsServer { 


// 上 级 DNS 是 谁 
private DnsServer UpperServer ; 
// 解 析 域 名 


public final Recorder resolve(String domain)t{ 


" + this.domain; 


" + this.ip; 
" + this.owner; 


Recorder recorder=null; 


， 可 以 直接 把 
如 代码 清单 32- 


if(isLocal(domain)){// 是 本 服务 器 能 解析 的 域名 
recorder = echo(domain); 
}else{// 本 服务 器 不 能 解析 
// 提 交 上 级 DNS 进 行 解析 
recorder = upperServer.resolve(domain); 


} 
return recorder; 

} 

// 指 向 上 级 DNS 

public void setUpperServer(DnsServer _upperServer)t{ 
this.upperServer = _upperServer,; 


} 
// 每 个 DNS 都 有 一 个 数据 处 理 区 (ZONE) ,检查 域名 是 否 在 本 区 中 
protected abstract boolean isLocal(String domain); 
// 每 个 DNS 服务 器 都 必须 实现 解析 任务 
protected Recorder echo(String domain)t{ 

Recorder recorder = new Recorder(); 

// 获 得 IP 地 址 

recorder.setIip(genIpAddress()); 

recorder ,SetDomain(domain ) ， 

return recorder; 


} 
// 随 机 产生 一 个 IP 地 址 ， 工 具 类 
private String genIpAddress(){ 

Random rand = new Random( ); 

String address = rand.nextInt(255) + "." + 
rand.nextInt(255) + "."+ rand.nextInt(255) + "."+ 
rand.nextInt(255); 

return address; 

} 


在 该 类 中 有 一 个 方法 一 一 genIpAddress 方 法 一 一 没有 在 类 图 中 展现 
出 来 ， 它 用 于 实现 随机 生成 卫 地 址 ， 这 是 我 们 为 模拟 DNS 解析 场景 而 建 
立 的 一 个 虚拟 方法 ， 在 实际 的 应 用 中 是 不 可 能 出 现 的 。 抽 象 DNS 服 务 器 
编写 完成 ， 我 们 再 来 看 具体 的 DNS 服务 器 ， 先 看 上 海 的 DNS 服务 器 ， 如 
代码 清单 32-33 所 示 。 


代码 清单 32-33 上 海 DNS 服 务 器 


public class SHDnsServer extends DnsServer { 
@Override 
protected Recorder echo(String domain) { 
Recorder recorder= Super.echo(domain ) ， 
recorder .setOwner ("上 海 DNS 服 务 器 " ) ; 
return recorder; 


} 

// 定 义 上 海 的 DNS 服 务 器 能 处 理 的 级 别 

@Override 

protected boolean isLocal(String domain) { 
return domain.endsWith(".sh.cn"); 

} 


为 什么 要 履 写 echo 方 法 ”各 具体 的 DNS 服务 器 实现 自己 的 解析 过 
程 ， 属 于 个 性 化 处 理 ， 它 代表 的 是 每 个 DNS 服务 器 的 不 同 处 理 逻 辑 。 还 
要 注意 一 下 ， 我 们 在 这 里 做 了 一 个 简化 处 理 ， 所 有 以 ".sh.cn" 结 尾 的 域名 
都 由 上 海 DNS 服 务 锅 解析。 其 他 的 中 国 顶 级 DNS 和 全 球 顶 级 DNS 实 现 过 
程 类 似 ， 如 代码 清单 32-34、32-35 所 示 。 


代码 清单 32-34 中 国 顶 级 DNS 服务 器 


public class ChinaTopDnsServer extends DnsServer { 
QOverride 
protected Recorder echo(String domain) { 
Recorder recorder = super.echo(domain); 
recorder ,setowner(" 中 国 顶 级 DNS 服务 器 " ) ， 
return recorder 


Q@override 

protected boolean isLocal(String domain) { 
return domain.endswith(".cn"); 

} 


代码 清单 32-35 全 球 顶 级 DNS 服务 器 


public class TopDnsServer extends DnsServer { 
@Override 


protected Recorder echo(String domain) { 
Recorder recorder = super.echo(domain); 
recorder .setOwner(" 全 球 顶 级 DNS 服务 器 " ) ; 
return recorder; 


Q@override 
protected boolean isLocal(String domain) { 
// 所 有 的 域名 最 终 的 解析 地 点 


return true,; 


所 有 的 DNS 服 务 器 部 准 备 好 了 ， 下 面 我 们 写 一 个 客户 问 来 模拟 一 下 
IP 地 址 是 怎么 解析 的 ， 如 代码 清单 32-36 所 示 。 


代码 清单 32-36 场景 类 


public class Client { 
public static void main(String[|] args) throws Exception { 

// 上 海域 名 服务 器 
DnsServer sh = new SHDnsServer(); 
// 中 国 顶 级 域名 服务 器 
DnsServer china = new ChinaTopDnsServer(); 
// 全 球 顶级 域名 服务 器 
DnsServer top = new TopDnsServer(); 
// 定 义 查 询 路 径 
china.setUpperServer(top); 
sh.setUpperServer(china); 


// 解 析 域 名 
System .OUt. println ( "===== 域 名 解析 模拟 器 =====" ) > 
while(true)t 


System.out .print("\n 请 输入 域名 (输入 N 退 出 ):"); 
String domain = (new BufferedReader (new 
InputStreamReader (System.in))).readLine(); 
if(domain.equalsIgnoreCase("n"))t 
return,; 


Recorder recorder = sh.resolve(domain); 
System.out .println("----DNS 服 务 器 解析 结果 - --- 


"); 


System.out.println(recorder); 


我 们 来 模拟 一 下 ， 运 行 结 采 如 下 所 示 : 


请 输入 域名 (输入 N 退 出 ):www.xxx.sh.cn 


| 


-DNS 服务 器 解析 结果 ---- 


域名 : www. xxx.sh.cn 


IP 地 址 : 69.224.162.154 


解析 者 : 上海 DNS 服 务 器 


请 输入 域名 (输入 N 退 出 ):www. xxx.com.cn 


| 


----DNS 服 务 器 解析 结 采 ---- 


域名 : www. xxx.com.cn 


IP 地 址 : 51.28.66.140 


解析 者 : 中 国 顶 级 DNS 服务 器 


请 输入 域名 (输入 N 退 出 ):www. xxx.com 


| 


----DNS 服 务 器 解析 结 采 ---- 


域名 : www. xxx.com 


IP 地 址 : 73.247.80.117 


解析 者 : 全球 顶级 DNS 服 务 器 


请 输入 域名 (输入 N 退 出 ):n 


请 注意 看 运行 


吉 果 ， 以 ".sh.cn" 结 尾 的 域名 人 确实 由 上 海 DNS 服 务 器 解 


析 了 ， 以 ".cn" 结 尾 的 域名 由 中 国 顶级 DNS 服务 右 解 术 了 ， 其 他 域名 都 由 


全 球 顶 级 DNS 服务 


器 解析 。 这 个 模拟 过 程 看 起 来 很 完整 ， 它 完全 就 古 责 


任 链 模式 的 一 个 具体 应 用 ， 把 一 个 请 求 放置 到 链 中 的 首 节 点 ， 然 后 由 链 
中 的 某 个 节点 进行 解析 并 将 结果 反馈 给 调用 者 。 但 是 ， 我 可 以 负责 任 地 
告诉 你 ， 这 个 解析 过 程 是 有 缺陷 的 ， 什 么 缺陷 ? 后 面 会 说 明 。 


32.3.2 触发 链 模 式 实现 DNS 解析 过 程 


上 面 说 到 使 用 责任 链 模式 模拟 DNS 解析 过 程 是 有 缺陷 的 ， 究 竟 有 什 
么 缺陷 ? 大 家 是 不 是 觉得 这 个 解析 过 程 很 完美 了 ， 没 什么 问题 了 ? 那 说 
明 你 对 DNS 协议 了 解 得 还 不 太 深入 。 我 们 来 做 一 个 实验 ， 在 dos 窗 口 下 
输入 nslookup 命 令 ， 然 后 输入 多 个 域名 ， 注 意 观察 返回 值 有 哪些 数据 是 
相同 的 。 可 以 看 出 ， 解 析 痢 都 相同 ， 都 旦 由 同一 个 DNS 服务 器 解析 的 ， 
准确 地 说 都 是 由 本 机 配置 的 DNS 服务 需 做 的 解析。 这 与 我 们 上 面 的 模拟 
过 程 是 不 相同 的 ， 看 看 我 们 模拟 的 过 程 ， 对 请 求 者 来 说 ，".sh.cn" 是 由 区 
域 DNS 解 析 的 ，".com" 却 是 由 全 球 顶 级 DNS 解析 的 ， 与 真实 的 过 程 不 相 
同 ， 这 是 怎么 回 事 呢 ? 


肯定 地 说 ， 采 用 责任 链 模 式 模拟 DNS 解析 过 程 是 不 完美 的 ， 或 者 说 
是 有 缺陷 的 ， 怎 么 来 修复 这 个 缺陷 呢 ? 我 们 先 来 看 看 真实 的 DNS 解析 过 
程 ， 如 图 32-9 所 示 。 


上 海 DNS 


图 32-9 真实 的 DNS 解析 示意 图 


解析 一 个 域名 的 完整 路 径 如 图 32-9 中 的 标号 ~ 所 示 ， 首 先 由 请 
求 者 发 送 一 个 请 求 ， 然 后 由 上 海 DNS 服 务 器 尝试 解析 ， 若 不 能 解析 再 通 
过 路 径 (2) 转 发 给 中 国 顶 级 DNS 进 行 解析 ， 解 析 后 的 结果 通过 路 径 (3) 返 回 
给 上 海 DNS 服 务 器 ， 然 后 由 上 海 DNS 服 务 器 通过 路 径 (6) 返 回 给 请 求 者 。 
同样 ， 铬 中 国 顶 级 DNS 不 能 解析 ， 则 通过 路 径 (3) 转 由 全 球 顶级 DNS 进 行 
解析 ， 通 过 路 径 (4) 把 结 采 返 回 给 中 国 顶级 DNS， 然 后 再 通过 路 径 (5) 返 回 
给 上 海 DNS。 注 意 看 标号 (6)， 不 管 一 个 域名 最 终 由 谁 解析 ， 最 终 反馈 到 
请 求 者 的 还 是 第 一 个 节点 ， 也 就 是 说 首 世 点 负责 对 请 求 者 应 答 ， 其 他 世 
点 都 不 与 请 求 者 交互 ， 而 只 与 目 己 的 左右 节点 交互 。 实 际 上 我 们 的 DNS 
服务 希 确 实 是 如 此 处 理 的 ， 例 如 本 机 请 求 查询 一 个 www.abcdefg.com 的 
域名 ， 上 海 DNS 服务 闫 解析 不 到 这 个 域名 ， 于 是 提交 到 中 国 顶级 DNS 服 
务 器 ， 如 有 果 中 国 顶级 DNS 服务 器 有 该 域名 的 记录 ， 则 找到 该 记录 ， 反 馈 
到 上 海 DNS 服务 右 ， 上 海 DNS 服 务 右 做 两 件 事务 处 理 : 一 是 啊 应 请 求 
者 ， 二 是 存储 该 记录 ， 以 备 其 他 请 求 者 再 次 查询 ， 这 类 似 于 数据 缓存 。 


整个 场景 我 们 已 经 清晰 ， 想 想 看 ， 我 们 把 请 求 者 看 成 是 被 观察 者 ， 
它 的 行为 或 属性 变更 通知 了 观察 者 一 上海 DNS， 上 海 DNS 又 作为 被 观 
察 者 出 现 了 自己 不 能 处 理 的 行为 (行为 改变 ) ， 通 知 了 中 国 顶 级 DNS ， 
依次 类 推 ， 这 是 不 是 一 个 非 肖 标准 的 触发 链 ? 而 且 还 必须 是 同步 的 触 
， 异 步 触 发 已 经 在 该 场景 中 失去 了 意义 (读者 可 以 想 想 为 什么 ) 


分 析 了 这 么 多 ， 我 们 用 触发 链 来 模拟 DNS 的 解析 过 程 ， 如 图 32-10 所 


<<interface>> 
java.util.Observer 


rr | 
+update(Observable arg0, Object arg1) 
+void setUpperServer(DnsServer dnsServer) 
#void sign(Recorder recorder) 
#0o0lean isLocal(Recorder recorder) 


java.util.Observable 


-String domain 
-String Pp 
-String owner 


TopDnsServer 


图 32-10 触发 链 模式 实现 DNS 解 析 的 类 图 


与 责任 链 模 式 很 相似 ， 仅 仅 多 了 一 个 Observable 父 类 和 Observer 接 
口 ， 但 是 在 实现 上 这 两 种 模式 有 非常 大 的 差异 。 我 们 先 来 解释 一 下 抽象 
DnsServer 的 作用 。 


e 标示 声明 


表示 所 有 的 DNS 服 务 器 都 具备 双重 身份 ， 既 是 观察 者 也 是 被 观察 
者 ， 这 很 重要 ， 它 声明 所 有 的 服务 器 都 具有 相同 的 身份 标志 ， 具 有 该 标 


志 后 就 可 以 在 链 中 随意 移动 ， 而 无 需 固 定 在 链 中 的 某 个 位 置 (这 也 是 链 
的 一 个 重要 特性 ) 。 


e 业务 抽象 


方法 setUpperServer 的 作用 是 设置 父 DNS， 也 就 是 设置 自己 的 观察 
者 ，update 方 法 不 仅仅 是 一 个 事件 的 处 理 者 ， 也 同时 是 事件 的 触发 者 。 


我 们 来 看 代码 ， 首 先是 最 简单 的 ，Recorder 类 与 责任 链 模 式 中 的 记 
了 永 相 同 ， 这 里 不 再 警 述 。 那 我 们 束 移 看 看 该 模式 的 核心 抽象 DnsServer， 
如 代码 清单 32-37 所 示 。 


代码 清单 32-37 抽象 DNS 服务 需 


public abstract class DnsServer extends Observable implements 
Observer { 
// 处 理 请 求 ， 也 就 是 接收 到 事件 后 的 处 理 
public void update(Observable arg0, Object arg1) { 
Recorder recorder = (Recorder)argil; 
// 如 果 本 机 能 解析 
if(isLocal(recorder))t 
recorder.setIip(genIpAddress( )); 
}else{// 本 机 不 能 解析 ， 则 提交 到 上 级 DNS 


responsFromUpperServer (recorder ) ; 


} 
// 签 名 
sign(recorder ); 


} 

// 作 为 被 观察 者 ， 人 允许 增加 观察 者 ， 这 里 上 级 DNS 一 般 只 有 一 个 

public void setUpperServer(DnsServer dnsServer)t{ 
// 先 清空 ， 然 后 再 增加 
super.deleteObservers( ); 
Super .addobserver(dnsServer ); 


// 回 父 DNS 请 求解 机 ， 也 就 是 通知 观察 者 
private void responsFromUpperServer(Recorder recorder ){ 
super.setchanged( ); 


Super .notifyobservers(recorder ) 


} 

// 每 个 DNS 服务 器 签 上 目 己 的 名 字 
protected abstract void sign(Recorder recorder ) ; 

// 每 个 DNS 服务 器 都 必须 定义 自己 的 处 理 级 别 

protected abstract boolean isLocal(Recorder recorder ) ; 
// 随 机 产生 一 个 IP 地 址 ， 工 具 类 

private String genIpAddress(){ 

Random rand = new Random( ); 

String address = rand.nextInt(255) + "." + 
rand.nextInt(255) + "."+ rand.nextInt(255) + "."+ 
rand.nextInt(255); 

return address ; 

} 


注意 看 一 下 responseFromUpperServer 方 法 ， 它 只 允许 设置 一 个 观察 
者 ， 因 为 一 般 的 DNS 服务 器 都 只 有 一 个 上 级 DNS 服务 器。sign 方 法 是 签 
和 名， 这 个 记录 是 由 谁 解析 出 来 的 ， 就 由 各 个 实现 类 独自 来 实现 。 三 个 
DnsServer 的 实现 类 都 比较 简单 ， 如 代码 清单 32-38、32-39、32-40 所 示 。 


代码 清单 32-38 上 海 DNS 服 务 器 


public class SHDnsServer extends DnsServer { 
@Override 
protected void sign(Recorder recorder) { 
recorder .setOwner ("上 海 DNS 服 务 器 " ) ; 


} 
// 定 义 上 海 的 DNS 服 务 器 能 处 理 的 级 别 
QOverride 
protected boolean isLocal(Recorder recorder) { 
return recorder.getDomain().endswith(".sh.cn"); 
} 


代码 清单 32-39 中 国 顶 级 DNS 服务 器 


public class ChinaTopDnsServer extends DnsServer { 
Q@Override 
protected void sign(Recorder recorder) { 
recorder ,setowner(" 中 国 顶级 DNS 服务 器 " ) ， 


@Override 

protected boolean isLocal(Recorder recorder) { 
return recorder.getDomain().endswith(".cn"); 

} 


代码 清单 32-40 全 球 顶 级 DNS 服 务 器 


public class TopDnsServer extends DnsServer { 
Q@Override 
protected void sign(Recorder recorder) { 
recorder .setOwner ("全 球 顶 级 DNS 服 务 器 ")， 
} 


Q@Override 
protected boolean isLocal(Recorder recorder) { 
// 所 有 的 域名 最 终 的 解析 地 点 


return true,; 


我 们 再 建立 一 个 场景 类 模拟 一 下 DNS 解析 过 程 ， 如 代码 清单 32-41 所 


人 小 ° 


代码 清单 32-41 场景 类 


public class Client { 
public static void main(String[|] args) throws Exception { 

// 上 海域 名 服务 器 
DnsServer sh = new SHDnsServer(); 
// 中 国 顶 级 域名 服务 器 
DnsServer china = new ChinaTopDnsServer(); 
// 全 球 顶 级 域名 服务 器 
DnsServer top = new TopDnsServer(); 
// 定 义 查 询 路 径 
china,.SsetUpperServer(top ) ; 
sh.setUpperServer(china); 


// 解 析 域 名 
System .OUt. println ( "===== 域 名 解析 模拟 器 =====" ) > 
while(true)t 


System.out.print("\n 请 输入 域名 (输入 N 退 出 ):"); 
String domain = (new BufferedReader (new 


InputStreamReader (System.in))).readLine(); 
if(domain.equalsIgnoreCase("n"))t 
return,; 
} 


Recorder recorder = new Recorder(); 
recorder ,SetDomain(domain ) ， 
sh.update(null,recorder); 

System.out .println("----DNS 服 务 器 解析 结果 - --- 


"); 


System.out.println(recorder); 


与 责任 链 模式 中 的 场景 类 很 相似 。 读 者 请 注意 
sh.update(null,recorder) 这 人 句 代码 ， 这 古 我 们 虚拟 了 观察 者 触发 动作 ， 完 
整 的 做 法 是 把 场景 类 作为 一 个 被 观察 者 ， 然 后 设置 观察 者 为 上 海 DNS 服 
务 器 ， 再 进行 测试 ， 其 结果 完全 相同 ， 我 们 这 里 为 减少 代码 量 采 用 了 人 简 
化 处 理 ， 有 兴趣 的 读者 可 以 扩充 实现 。 


我 们 来 看 看 运行 结 采 如 何 ， 结 果 如 下 所 示 : 


请 输入 域名 (输入 N 退 出 ):www.xxx.sh.cn 


----DNS 服 务 器 解析 结 采 ---- 


域名 : www.xxx.sh.cn 


IP 地 址 : 197.15.34.227 


解析 者 : 上 海 DNS 服 务 器 


请 输入 域名 (输入 N 退 出 ):www.XXxx.com.cn 


----DNS 服 务 器 解析 结果 ---- 


域名 : www.xxx.com.cn 


IP 地 址 : 201.177.148.99 


解析 者 : 上 海 DNS 服 务 器 


请 输入 域名 (输入 N 退 出 ):www.xxx.com 


-DNS 服务 器 解析 结果 ---- 


域名 : www.xxx.com 


IP 地 址 : 251.41.14.230 


解析 者 : 上 海 DNS 服 务 器 


请 输入 域名 (输入 N 退 出 ):n 


可 以 看 出 ， 所 有 的 解析 结 采 都 是 由 上 海 DNS 服务 器 返回 的 ， 这 才 是 
真正 的 DNS 解 析 过 程 。 如 何 知 道 它 是 由 上 海 DNS 服 务 右 解析 的 还 是 由 别 
的 DNS 服务 器 解析 的 呢 ? 很 好 办 ， 把 代码 捞 贝 过 去 ， 然 后 调试 跟踪 一 下 
忠 可 以 了 。 或 者 仔细 看 看 代码 ， 理 解 一 下 代码 逻辑 也 可 以 非常 清楚 地 知 
道 它 是 如 何 解析 的 。 


再 仔细 看 一 下 我 们 的 代码 逻辑 ， 上 下 两 个 市 点 之 间 的 天 系 很 微妙 ， 
很 有 意思 。 


e 下 级 节点 对 上 级 节点 顶礼 膜拜 


比如 我 们 输入 的 这 个 域名 www.xxx.com， 上 海域 名 服务 器 只 知道 它 
是 由 父 节 点 (中国 顶级 DNS 服 务 器 ) 解析 的 ， 而 不 知道 父 厄 点 把 该 请 求 
转发 给 了 更 上 层 节 点 (全 球 顶级 DNS 服 务 器 ) ， 也 就 是 说 下 级 节点 关注 
的 是 上 级 节点 的 响应 ， 只 要 是 上 级 反馈 的 结果 就 认为 是 上 级 的 。 


wwwXXx.com 这 个 域名 最 终 是 由 最 高 入 点 (全 球 顶级 DNS 服 务 器 ) 解析 
的 ， 它 把 解析 结果 传递 给 第 二 个 节点 (中 国 顶级 DNS 服 务 器 ) 时 的 签名 
为 “全 球 顶级 DNS 服 务 器 *， 而 第 二 个 节点 把 请 求 传递 给 首 节 点 (上 海 
DNS 服 务 器 ) 时 的 签名 被 修改 为 “中 国 顶级 DNS 服 务 器 *”。 所 有 从 上 级 广 
点 反馈 的 响应 都 认为 是 上 级 节点 处 理 的 结果 ， 而 不 追究 到 底 是 不 是 真 的 
是 上 级 市 护 处 理 的 。 


e 上 级 节点 对 下 级 节点 绝对 信任 


上 级 市 点 只 对 下 级 节点 负责 ， 它 不 关心 下 级 节点 的 请 求 从 何 而 来 ， 
只 要 是 下 级 发 送 的 请 求 就 认为 是 下 级 的 。 还 是 以 www.xxx.com 域 名 为 
例 ， 当 最 高 节点 (全 球 顶 级 DNS 服 务 器 ) 获得 解析 请 求 时 ， 它 认为 这 个 
请 求 是 谁 的 ? 当然 是 第 二 个 节点 (中 国 顶 级 DNS 服 务 器 ) 的 ， 否 则 它 也 
不 会 把 结 采 反馈 给 它 ， 但 是 这 个 请 求 的 源头 却 是 首 世 点 (上 海 DNS 服 务 
器 ) 的 。 


723 省 


通过 对 DNS 解 析 过 程 的 实现 ， 我 们 发 现 触 发 链 和 责任 链 虽 然 都 十 链 
结构 ， 但 是 还 是 有 区 别 的 。 


e 链 中 的 消息 对 象 不 同 


从 首 节 点 开始 到 最 终 的 尾 节 点 ， 两 个 链 中 传递 的 消息 对 象 古 不 同 

的 。 责 任 链 模式 基本 上 不 改变 消息 对 象 的 结构 ， 虽 然 每 个 节点 都 可 以 参 
与 消费 (一 般 是 不 参与 消费 ) ， 类 似 于 “ 雁 过 拔 毛 ”， 但 是 它 的 结构 不 会 
改变 ， 比 如 从 首 节点 传递 进来 一 个 String 对 象 或 者 Person 对 象 ， 不 会 到 链 
尾 的 时 候 成 了 int 对 象 或 者 Human 对 象 ， 这 在 贡 任 链 模 式 中 是 不 可 能 的 ， 
但 是 在 触发 链 模 式 中 是 允许 的 ， 链 中 传递 的 对 象 可 以 目 由 变化 ， 只 要 上 
下 级 节点 对 传递 对 象 了 解 即 可 ， 它 不 要 求 链 中 的 消息 对 和 象 不 变化 ， 它 只 
要 求 链 中 相 邻 两 个 市 点 的 消息 对 象 固定 。 


e 上 下 下 点 的 关系 不 同 


在 责任 链 模式 中 ， 上 下 节点 没有 关系 ， 都 是 接收 同样 的 对 象 ， 所 有 
传递 的 对 象 都 是 从 链 首 传递 过 来 ， 上 一 节点 是 什么 没有 关系 ， 只 要 按照 
自己 的 逻辑 处 理 就 成 。 而 触发 链 模 式 束 不 同 了 ， 它 的 上 下 级 关系 很 亲 
密 ， 下 级 对 上 级 顶礼 膜拜 ， 上 级 对 下 级 绝对 信任 ， 链 中 的 任意 两 个 相 邻 
节点 都 是 一 个 牢固 的 独立 团体 。 


e 消息 的 分 销 渠道 不 同 


在 责任 链 模式 中 ， 一 个 消息 从 链 首 传递 进来 后 ， 束 开始 沿 着 链条 加 
链 尾 运动 ， 方 向 是 单一 的 、 固 定 的 ;而 触发 链 模式 则 不 同 ， 由 于 它 采 用 
的 是 观察 者 模式 ， 所 以 有 非常 大 的 灵活 性 ， 一 个 消 妃 传递 到 链 首 后 ， 具 
体 皇 么 传递 是 不 固定 的 ， 可 以 以 广播 方式 传递 ， 也 可 以 以 跳跃 方式 传 
递 ， 这 取决 于 处 理 消 息 的 逻辑 。 


第 33 章 ” 跨 战 区 PK 


创建 类 模式 描述 如 何 创建 对 象 ， 行 为 类 模式 关注 如 何 管理 对 象 的 
行为 ， 结 构 类 模式 则 着 重 于 如 何 建立 一 个 软件 结构 ， 虽 然 三 种 模式 的 
着 重点 不 同 ， 但 是 在 实际 应 用 中 还 是 有 重合 的 ， 会 出 现 一 种 模式 适 
用 、 男 外 一 种 模式 也 适用 的 情况 ， 我 们 到 瓜 该 选用 哪 一 个 设计 模式 
呢 ? 本 章 就 带领 读者 进入 不 同类 设计 模式 PK 的 世界 中 ， 让 你 清晰 地 认 
识 到 各 个 模式 的 不 同 点 以 及 它们 的 特长 。 


33.1 策略 模式 VS 桥梁 模式 


这 对 冤家 终于 页 头 了 ， 策 略 模 式 与 桥梁 模式 是 如 此 相似 ， 简 直 整 
是 挛 生 兄弟 ， 要 把 它们 两 个 分 开 可 不 太 容 易 。 我 们 来 看 看 两 者 的 通用 
类 图 ， 如 图 33-1 所 示 。 


Context RE 、 Strategy Abstraction |—~ +imp > Tmplementor 
+ContextInterface() +AlgorithmInterface() +Operation() +Operationhmp() 
ConcreteStrategy RefinedAbstraction ConcreteImplementor 
F 


图 33-1 策略 模式 ( 左 ) 和 桥梁 模式 ( 右 ) 通用 类 图 


两 者 之 间 确 实 很 相似 。 如 果 把 策略 模式 的 环境 角色 变更 为 一 个 抽 
象 关 加 一 个 实现 类 ， 或 者 桥梁 模式 的 抽象 角色 未 实现 ， 只 有 修正 抽象 
化 角色 ， 想 想 看 ， 这 两 个 类 图 有 什么 地 方 不 一 样 ? 完全 一 样 ! 正 是 由 
于 类 似 场景 的 存在 才 导 致 了 两 关 在 实际 应 用 中 经 音 视 清 的 情况 发 生 ， 
我 们 来 举例 说 明 两 着 有 何 老 别 。 


大 家 都 知道 邮件 有 两 种 格式 : 文本 邮件 (Text Mail) 和 超 文本 邮 
件 (HTML MaiL) ,在 文本 邮件 中 只 能 有 人 简单 的 文字 信息 ， 而 在 超 文 本 
邮件 中 可 以 有 复杂 文字 ( 带 有 颜色 、 字 体 等 属性 ) 、 图 片 、 视 频 等 ， 
如 膝 你 使 用 Foxmail 邮 件 客户 端的 话 束 应 该 有 深刻 体验 ， 看 到 一 份 邮 
件 ， 脏 么 没 内 容 ? 原来 是 你 起 记 扩 击 那个 “HTML 邮 件 ” 标 多 了 。 下 面 我 


们 束 来 讲解 如 何 发 送 这 两 种 不 同 格式 的 邮件 ， 人 研究 一 下 这 两 种 模式 如 
何 处 理 这 样 的 场景 。 


33.1.1 策略 模式 实现 邮件 发 送 


使 用 策略 模式 发 送 邮件 ， 我 们 认为 这 两 种 邮件 是 两 种 不 同 的 封装 
格式 ， 给 定 了 发 件 人 、 收 件 人 、 标 题 、 内 容 的 一 封 邮 件 ， 按 照 两 种 不 
同 的 格式 分 别 进行 封装 ， 然 后 发 送 之 。 按 照 这 样 的 分 析 ， 我 们 发 现 邮 
件 的 两 种 不 同 封装 格式 就 是 两 种 不 同 的 算法 ， 具 体 到 策略 模式 就 是 两 
种 不 同 策略 ， 这 样 看 已 经 很 简单 了 ， 我 们 可 以 直接 套用 策略 模式 来 实 
现 。 先 看 类 图 ， 如 图 33-2 所 示 。 
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图 33-2 策略 模式 实现 邮件 发 送 的 类 图 


我 们 定义 了 一 个 邮件 模板 ， 它 有 两 个 实现 类 : TextMail (文本 邮 
件 ) 和 HtmlMail 〈 超 文本 邮件 ) ， 分 别 实现 两 种 不 同 格式 的 邮件 圭 
装 。MailServer 是 一 个 环境 角色 ， 它 接收 一 个 MailTemplate 对 象 ， 然 后 
通过 sendMail 方 法 发 送出 去 。 我 们 来 看 具体 的 代码 ， 先 看 抽象 邮件 ， 如 
代码 清单 33-1 所 示 。 


代码 清单 33-1 抽象 邮件 


public abstract class MailTemplate { 
// 邮 件 发 件 人 
private String from; 
// 收 件 人 
private String to; 
// 邮 件 标题 
private String subject; 
// 邮 件 内 容 
private String context; 
// 通 过 构造 画 数 传递 邮件 信息 
public MailTemplate(String _from,String _to,String 
_Subject,String _context){ 


this.from = _from; 
this.to = _to; 
this.subject = _subject; 
this.context = _context; 


} 
public String getFrom() { 
return from， 


public void setFrom(String from) { 
this,from = from; 


} 
public String getTo() { 
return to; 


} 

public void setTo(String to) { 
this.to = to; 

} 


public String getSubject() { 
return Subject 


} 
public void setSubject(String subject) { 
this.subject = subject; 


} 
public void setContext(String context){ 
this.context = context; 


} 

// 邮 件 都 有 内 容 

public String getContext(){ 
return context,; 

和 


很 奇怪 ， 是 吗 ? 抽象 类 没有 抽象 的 方法 ， 设 置 为 抽象 类 还 有 什么 
意义 呢 ? 有 意义 ， 在 这 里 我 们 定义 了 一 个 这 样 的 抽象 类 : 它 具 有 邮件 
的 所 有 属性 ， 但 不 是 一 个 具体 可 以 被 实例 化 的 对 象 。 例 如 ， 你 对 邮件 
服务 郁 说 “给 我 制造 一 封 邮 件 ”， 邮 件 服务 夯 肯 定 拒绝 ， 为 什么 ? 你 要 
产生 什么 邮件 ? 什么 格式 的 ? 邮件 对 邮件 服务 器 来 说 是 一 个 抽象 表 
示 ， 是 一 个 可 描述 但 不 可 形象 化 的 事物 。 你 可 以 这 样 说 : “我 要 一 封 标 
题 为 XX， 发 件 人 站 XXX 的 文本 格式 的 邮件 ”， 这 束 是 一 个 可 实例 化 的 
对 象 ， 因 此 我 们 的 设计 就 产生 了 两 个 子 类 以 具体 化 邮件 ， 而 且 每 种 邮 
件 格 式 对 邮件 的 内 容 都 有 不 同 的 处 理 。 我 们 首 移 看 文本 邮件 ， 如 代码 
清单 33-2 所 示 。 


代码 清单 33-2 文本 邮件 


public class TextMail extends MailTemplate { 
public TextMail(String _from, String _to, String _subject, 
String _context) { 
super(_from, _to, _subject, _context); 


} 
public String getContext() { 


// 文 本 类 型 设置 邮件 的 格式 为 : text/plain 

String context = "ANnContent -Type : 
text/plain;charset=GB2312\n" +Super .getContext( ) ; 

// 同 时 对 邮件 进行 base64 编 码 处 理 , 这 里 用 一 句 话 代替 

context = context + "xn 邮件 格式 为 : 文本 格式 "; 

return context 


我 们 履 写 了 getContext 方 法 ， 因 为 要 把 一 封 邮 件 设置 为 文本 邮件 必 
须 加 上 一 个 特殊 的 标志 : text/plain， 用 于 告诉 解析 这 份 邮件 的 客户 
端 : “我 是 一 封 文 本 格式 的 邮件 ， 别 解析 错 了 ”。 同样 ， 超 文本 格式 的 
邮件 也 有 类 似 的 设置 ， 如 代码 清单 33-3 所 示 。 


代码 清单 33-3 超 文本 邮件 


public class HtmlMail extends MailTemplate { 
public HtmlMail(String _from, String _to, String _subject, 
String _context) { 
super(_from, _to, _subject, _context); 


} 
public String getContext(){ 
// 超 文本 类 型 设置 邮件 的 格式 为 : multipart/mixed 
String context = "AnContent -Type: multipart/mixed; 
charset= GB2312\n" +Super .getContext() ; 
// 同 时 对 邮件 进行 HTML 检 查 ， 是 否 有 类 似 未 关闭 的 标签 
context = context + "Nn 邮 件 格式 为 : 超 文本 格式 "， 


return context,; 


优秀 一 点 的 邮件 客户 端 会 对 邮件 的 格式 进行 检查 ， 比 如 编写 一 封 
超 文本 格式 的 邮件 ， 在 内 容 中 加 上 了 <font> 标 和 俭 ， 但 是 遗 筷 了 </font> 结 
尾 标签 ， 邮 件 的 产生 者 (也 就 是 邮件 的 客户 端 ) 会 提示 进行 修正 ， 我 
们 这 里 用 了 “邮件 格式 为 ， 超 文本 格式 ”来 代表 该 逻辑 。 


两 个 实现 类 实现 了 不 同 的 算法 ， 给 定 相 同 的 发 件 人 、 收 件 人 、 标 
题 和 内 容 可 以 产生 不 同 的 邮件 信息 。 我 们 看 看 邮件 是 如 何 发 送出 去 
的 ， 如 代码 清单 33-4 所 示 。 


代码 清单 33-4 邮件 服务 器 


public class MailServer { 
// 发 送 的 是 哪 封 邮件 
private MailTemplate m; 
public MailServer(MailTemplate _m){ 
this.m = _m; 


} 

// 发 送 邮 件 

public void sendMail(){ 
System,.out ,printlLn("==== 正 在 发 送 的 邮件 信息 ====") 
// 发 件 人 
System.out.println(" 发 件 人 : " + m,getFrom() ); 
// 收 件 人 
System.out.println(" 收 件 人 : " + m,getTo() ); 
// 标 题 
System,out,println(" 邮 件 标题 : " + m.getSubject()); 
// 邮 件 内 容 
System,out,println(" 邮 件 内 容 : " + m.getContext()); 


很 简单 ， 邮 件 服 务 器 接收 了 一 封 邮 件 ， 然 后 调用 自己 的 发 送 程序 
进行 发 送 。 可 能 读者 要 问 了 ， 为 什么 不 把 sendMail 方 法 移植 到 邮件 模板 
类 中 呢 ? 这 也 是 邮件 模板 类 的 一 个 行为 ， 邮 件 可 以 被 发 送 。 是 的 ， 这 
确实 古 邮件 的 一 个 行为 ， 完 全 可 以 这 样 做 ， 两 者 没有 什么 区 别 ， 只 是 
从 不 同 的 角度 看 待 该 方法 而 已 。 我 们 继续 看 场景 类 ， 如 代码 清单 33-5 所 


修 ° 


代码 清单 33-5 场景 类 


public class Client { 
public static void main(String[] args) { 
// 创 建 ee 
MailTemplate m = ne 
HtmlMail("a@a.com", "b@b .com", "外 息 人 攻击 地 球 了 " "结局 是 外 星人 被 地 球 人 
打败 了 ! "); 


// 创 建 一 个 Mail 发 送 程序 
MailServer mail = new MailServer(m); 
// 发 送 邮 件 


mail.sendMail( ); 


证 


运行 结果 如 下 所 示 : 


==== 正 在 发 送 的 邮件 信息 


发 件 人 : a@a.com 


收 件 人 : b@b.com 


邮件 标题 : 外 星人 攻击 地 球 了 


邮件 内 容 ; 


Content-Type: multipart/mixed;charset=GB2312 


结局 是 外 星人 被 地 球 人 打败 了 ! 


==y 
全 


-格式 为 ， 超 文本 格式 


当然 ， 如 末 想 产生 一 封 文 本 格式 的 邮件 ， 只 要 稍稍 修改 一 下 场景 
类 束 可 以 了 : new HtmlMail 修 改 为 new TextMail， 读 者 可 以 自行 实现 ， 
非常 简单 。 在 该 场景 中 ， 我 们 使 用 党 略 模式 实现 两 种 算法 的 目 由 切 
换 ， 它 提供 了 这 样 的 保证 : 封 半 邮件 的 两 种 行为 是 可 选择 的 ， 至 于 选 
择 哪 个 算法 是 由 上 层 模块 决定 的 。 策 略 模式 要 完成 的 任务 束 是 提供 两 
种 可 以 车 换 的 算法 。 


33.1.2 桥梁 模式 实现 邮件 发 送 


桥梁 模式 关注 的 是 抽象 和 实现 的 分 离 ， 它 是 结构 型 模式 ， 结 构 型 
模式 研究 的 是 如 何 建 立 一 个 软件 架构 ， 下 面 我 们 就 来 看 看 桥梁 模式 是 
如 何 构件 一 套 发 送 邮 件 的 架构 的 ， 如 图 33-3 所 示 。 


类 图 中 我 们 增加 了 SendMail 和 了 Postfix 两 个 邮件 服务 器 来 实现 类 ， 在 
邮件 模板 中 允许 增加 发 送 痢 标记， 其 他 与 策略 模式 都 相同 。 我 们 在 这 
里 已 经 完成 了 一 个 独立 的 架构 ， 邮 件 有 了 ， 发 送 邮 件 的 服务 器 也 具备 
了 ， 是 一 个 完整 的 邮件 发 送 程序 。 和 需要 读者 注意 的 是 ，SendMail 类 不 
是 一 个 动词 行为 (发送 邮件 ， 它 指 的 是 一 款 开源 邮件 服务 器 产品 ， 
一 般 *nix 系 统 的 默认 邮件 服务 侨 就 是 SendMail;，Postfix 也 是 一 球 开 源 的 
邮件 服务 夯 产 品 ， 其 性 能 、 稳 定性 都 在 逐步 赶 超 SendMail 。 


-MailTemplate m -String from 
+MailServer(MailTemplate _m) ee ~ t 
+void sendMail() -String context 


+getter/setter() 
+void add(String sendInfo) 


作 


SendMail 


| 
+void sendMail() 


| | 
+void sendMail() 


| 
+String getContext() 


HtmlMail 
| 


+String getContext() 


SendMail 邮 件 服务 器 
Postfix 邮 件 服务 器 


图 33-3 桥梁 模式 实现 邮件 发 送 的 类 图 


我 们 来 看 代码 实现 ， 邮 件 模板 仅仅 增加 了 一 个 add 方 法 ， 如 代码 清 
单 33-6 所 示 。 


代码 清单 33-6 邮件 模板 


public abstract class MailTemplate { 
/* 
a bp 分 代码 不 变 ， 请 参考 代码 清单 33-1 
/外 许 增加 邮件 发送 标志 


public void add(String sendInfo){ 
context = SendInfo + Context 
} 


文本 邮件 、 超 文本 邮件 部 没有 任何 改变 ， 如 代码 清单 33-2、33-3 所 
这 里 不 再 费 述 。 


我 们 来 看 邮件 服务 器 ， 也 就 是 桥梁 模式 的 抽象 化 角色 ， 如 代码 清 
单 33-7 所 示 。 


代码 清单 33-7 邮件 服务 器 


public abstract class MailServer { 
// 发 送 的 是 哪 封 邮 件 
protected final MailTemplate m; 
public MailServer(MailTemplate _m){ 
this.m = _m; 


} 

// 发 送 邮 件 

public void sendMail( ){ 
System,.out ,printlLn("==== 正 在 发 送 的 邮件 信息 ====") 
// 发 件 人 
System.out.println(" 发 件 人 : " + m,getFrom() ); 


// 收 件 人 
System,out.printlLn(" 收 件 人 : " + m.getTo()); 


// 标 题 
System.out.println(" 邮 件 标 题 : " + m,getSubject() ); 
// 邮 件 内 容 


System,out,println(" 邮 件 内 容 : " + m.getContext()); 


该 类 相对 于 策略 模式 的 环境 角色 有 两 个 改变 : 


e 修改 为 抽象 类 。 为 什么 要 修改 成 抽象 类 ? 因为 我 们 在 设计 一 个 染 
构 ， 邮 件 服务 器 是 一 个 具体 的 、 可 实例 化 的 对 象 吗 ?“ 给 我 一 人 台 邮 件 服 
务 絮 ”能 实现 吗 ? 不 能 ， 只 能 说 “给 我 一 侣 Postfix 邮 件 服 务 郁 ”， 这 才能 


实现 ， 必 须 有 一 个 明确 的 可 指向 对 象 。 
e 变量 证 修改 为 Protected 访 问 权 限 ， 方 便 子 类 调用 。 
我 们 再 来 看 看 Postfix 邮 件 服 务 器 的 实现 ， 如 代码 清单 33-8 所 示 。 


代码 清单 33-8 Postfix 邮 件 服务 器 


public class Postfix extends MailServer { 
public Postfix(MailTemplate m) { 
super(_m); 


} 
// 修 正 邮 件 发 送 程序 
public void sendMail( ){ 
// 增 加 邮件 服务 器 信息 
String context ="Received: from XXXX (unknown 
[Xxx.xxx.xxx.xxx]) by aaa.aaa.com (Postfix) with ESMTP id 
8DBCD172B8\n" ， 
super.m.add(context ); 
super .sendMail( ); 


为 什么 要 徐 写 sendMail 程 序 呢 ?这 是 因为 每 个 邮件 服务 器 在 发 送 邮 
件 时 都 会 在 邮件 内 容 上 留 下 目 己 的 标志 ， 一 是 广告 作用 ， 二 是 为 了 互 
联网 上 统计 需要 ， 三 是 方便 同 质 软件 的 共振 。 我 们 再 来 看 SendMail 邮 
件 服务 万 的 实现 ， 如 代码 清单 33-9 所 示 。 


代码 清单 33-9 SendMail 邮 件 服务 器 


public class SendMail extends MailServer { 
// 传 递 一 封 邮件 
public SendMail(MailTemplate m) { 
super(_m); 


} 
// 修 正 邮 件 发 送 程序 
Q@Override 
public void sendMail( ){ 
// 增 加 邮件 服务 器 信息 
super.m.add("Received: (sendmail); 7 Nov 2009 
04:14:44 +0100"); 
super .sendMail( ); 
} 


邮件 和 邮件 服务 絮 都 有 了 ， 我 们 来 看 怎么 发 送 邮 件 ， 如 代码 清单 
33-10 所 示 。 


代码 清单 33-10 场景 


public class Client { 
public static void main(String[] args) { 
// 创 建 一 封 TEXT 格 式 的 邮件 
MailTemplate m = new 


HtmlMail("a@a.com", "b@b .com", "外 星人 攻击 地 球 了 "," 结局 是 外 星人 被 地 球 人 


打败 了 ! "); 
// 使 用 Postfix 发 送 邮 件 
MailServer mail = new Postfix(m); 
// 发 送 邮 件 


mail.sendMail( ); 


一 


运行 结果 如 下 所 示 : 


==== 正 在 发 送 的 邮件 信息 ==== 
发 件 人 : a@a.com 
收 件 人 : b@b.com 


邮件 标题 : 外 星人 攻击 地 球 了 


邮件 内 容 : 


Content-Type: multipart/mixed;charset=GB2312 


Received: from XXXX (unknown [XXX.XXX.XXX.XXX]) by aaa.aaa.com (Postfix) with ESMTP id 
8DBCD172B8 


结局 是 外 星人 被 地 球 人 打败 了 ! 


邮件 格式 为 : 超 文 本 格式 


当然 了 ， 还 有 其 他 三 种 发 送 邮 件 的 方式 Postfix 发 送 文本 邮件 以 及 
SendMail 发 送 文本 邮件 和 超 文本 邮件 。 修 改 量 很 小 ， 读 者 可 以 目 行 修 
改 实现 ， 体 会 一 下 桥梁 模式 的 特点 。 


33.1.3 最 佳 实践 
策略 模式 和 桥梁 模式 是 如 此 相似 ， 我 们 只 能 从 它们 的 意图 上 来 分 


析 。 人生 略 模式 是 一 个 行为 模式 ， 旨 在 封 疼 一 系列 的 行为 ， 在 例子 中 我 
们 认为 把 邮件 的 必要 信息 (发 件 人 、 收 件 人 、 标 题 、 内 容 ) 封装 成 一 


个 对 象 就 是 一 个 行为 ， 封 装 的 格式 (算法 ) 不 同 ， 行 为 也 就 不 同 。 而 
桥梁 模式 则 是 解决 在 不 破坏 封装 的 情况 下 如 何 抽 取出 它 的 抽象 部 分 和 
实现 部 分 ， 它 的 前 提 是 不 破坏 封 狼 ， 让 抽象 部 分 和 实现 部 分 都 可 以 独 
立地 变化 ， 在 例子 中 ， 我 们 的 邮件 服务 器 和 邮件 模板 是 不 是 都 可 以 独 
立地 变化 ? 不 管 是 邮件 服务 器 还 是 邮件 模板 ， 只 要 继承 了 抽象 类 束 可 
以 继续 扩展 ， 它 的 主旨 是 建立 一 个 不 破坏 封装 性 的 可 扩展 架构 。 


简单 来 说 ， 策 略 模式 是 使 用 继承 和 多 态 建立 一 套 可 以 自由 切换 算 
法 的 模式 ， 桥 架 模 式 是 在 不 破坏 封装 的 前 提 下 解决 抽象 和 实现 都 可 以 
独立 扩展 的 模式 。 桥 梁 模 式 必 然 有 两 个 “桥墩 "一 一 抽象 化 角色 和 实现 
化 角色 ， 只 要 桥墩 搭建 好 ， 桥 束 有 了 ， 而 集 略 模式 只 有 一 个 抽象 角 
色 ， 可 以 没有 实现 ， 也 可 以 有 很 多 实现 。 


还 是 很 难 区 分 ， 是 吧 ? 多 想 想 两 者 的 意图 ， 就 可 以 理解 为 什么 要 
建立 两 个 相似 的 模式 了 。 我 们 在 做 系统 设计 时 ， 可 以 不 考虑 到 说 使 用 
的 是 全 略 模式 还 十 桥 梁 模 式 ， 只 要 好 用 ， 能 够 解决 问题 束 成 '，“ 不 管 黑 
猫 日 猫 ， 抓 住 老 姐 的 束 是 好 猫 ”。 


33.2 门面 模式 VS 中 介 者 模式 


门面 模式 为 复业 的 子 系 统 提供 一 个 统一 的 访问 界面 ， 它 定义 的 是 一 
个 高 层 接口 ， 该 接口 使 得 子 系统 更 加 容易 使 用 ， 避 人 免 外 部 模块 深入 到 子 
系统 内 部 而 产生 与 子 系统 内 部 细节 耦合 的 问题 。 中 介 者 模式 使 用 一 个 中 
介 对 和 象 来 封 普 一 系列 同事 对 和 象 的 交互 行为 ， 它 使 各 对 和 象 之 间 不 再 显 式 地 
引用 ， 从 而 使 其 耦合 松散 ， 建 立 一 个 可 扩展 的 应 用 架构 。 


33.2.1 中 介 者 模式 实现 工资 计算 


大 家 工作 会 得 到 工资 ， 那 么 工资 与 哪些 因素 有 关 呢 ? 这 里 假设 工资 
与 职位 、 税 收 有 关 ， 职 位 提升 工资 就 会 增加 ， 同 时 税收 也 增加 ， 职 位 下 
降 了 工资 也 同步 降低 ， 当 然 税 收 也 降低 。 而 如 果 税 收 比率 增加 了 呢 ? 工 
资 自然 就 减少 了 ! 这 三 者 之 间 两 两 都 有 关系 ， 很 适合 中 介 者 模式 的 场 
景 ， 类 图 如 图 33-4 所 示 。 


AbsColleague 


<<Interface>> 
IPosition 


<<interface>> <<mterface>> 


只 位 工资 = 
抽象 中 介 者 
、 


sm 
EE 
图 33-4 工资 、 职 位 、 税 收 的 示意 类 图 


AbsMediator 


类 图 中 的 方法 比较 简单 ， 我 们 主要 分 析 的 是 三 者 之 间 的 关系， 通过 


类 图 可 以 发 现 三 者 之 间 已 经 没有 耦合 ， 原 本 在 需求 分 析 时 我 们 发 现 三 者 
有 直接 的 交互 ， 采 用 中 介 者 模式 后 ， 三 个 对 象 之 间 已 经 相互 独立 了 ， 全 
部 委托 中 介 者 完成 。 我 们 在 类 图 中 还 定义 了 一 个 抽象 同事 类 ， 它 是 一 个 
标志 性 接口 ， 其 子 类 都 是 同事 类 ， 都 可 以 被 中 介 者 接收 ， 如 代码 清单 
33-11 所 示 。 


代码 清单 33-11 抽象 同事 类 


public abstract class AbsColleague { 
// 每 个 同事 类 都 对 中 介 者 非常 了 解 
protected ADS Nei tor mediator; 
public AbsColleague(AbsMediator _mediator)t{ 
this.mediator = _mediator; 
} 


在 抽象 同事 类 中 定义 了 每 个 同事 类 对 中 介 者 都 非常 了 解 ， 如 此 才能 
把 请 求 委托 给 中 介 者 完成 。 三 个 同事 类 都 具有 相同 的 设计 ， 即 定义 一 个 
业务 接口 以 及 每 个 对 象 必须 实现 的 职责 ， 同 时 既然 是 同事 类 束 剖 继承 
AbsColleague。 抽象 同事 类 只 是 一 个 标志 性 父 类 ， 并 没有 限制 子 类 的 业 
务 逻 辑 ， 因 此 每 一 个 同事 类 并 没有 违 痛 单一 职 贡 原则 。 前 先 来 看 职位 接 
口 ， 如 代码 清单 33-12 所 示 。 


代码 清单 33-12 职位 接口 


public interface IPosition { 
// 升 职 
public void promote(); 
// 降 职 
public void demote( ); 


J 


职位 会 有 升 有 降 ， 职 位 变化 如 代码 清单 33-13 所 示 。 


代码 清单 33-13 职位 


public class Position extends AbsColleague implements IPosition 


public Position(AbsMediator _mediator)t{ 
Super(_mediator ) ; 


} 
public void demote() { 

super .mediator.down(this); 
; 


public void promote() { 
super .mediator .up(this); 
. 


每 一 个 职位 的 升降 动作 都 委托 给 中 介 者 执行 ， 具 体 一 个 职位 升降 影 
啊 到 谁 这 里 没有 定义 ， 完 全 由 中 介 者 完成 ， 位 单 而 且 扩 展 性 非 第 好 。 下 
面 我 们 来 看 工资 接口 ， 如 代码 清单 33-14 所 示 。 


代码 清单 33-14 工资 接口 


public interface ISalary { 
// 加 薪 
public void increaseSalary(); 
// 降 新 
public void decreaseSalary() ; 


工资 也 会 有 升 有 降 ， 如 代码 清单 33-15 所 示 。 


代码 清单 33-15 工资 


public class Salary extends AbsColleague implements ISalary { 
public Salary(AbsMediator _mediator)t{ 
super(_mediator ) ; 


public void decreaseSalary() { 
super .mediator. down(this); 


public void increaseSalary() { 
Super .mediator .up(this); 


交 税 是 公民 的 义务 ， 税 收 接口 如 代码 清单 33-16 所 示 。 
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代码 清单 33-16 税收 接口 


public interface ITax { 
// 税 收 上 升 
public void raise(); 


// 税 收 下 降 
public void drop(); 


税收 的 变化 对 我 们 的 工资 当然 有 影响 ， 如 代码 清香 33-17 所 示 。 


代码 清单 33-17 税收 


public class Tax extends AbsColleague implements ITax { 

// 注 入 中 介 者 

public Tet ADE ed ao _mediator){ 
super(_mediator ) ; 


} 
public void drop() { 
super .mediator. down(this); 


public void raise() { 
Super .mediator .up(this); 
} 


以 上 同事 类 的 业务 部 委托 给 了 中 介 者 ， 其 本 类 已 经 没有 任何 的 逻辑 
了 ， 非 常 简 单 ， 现 在 的 问题 是 中 介 者 类 非常 复 洒 ， 因 为 它 要 处 理 三 者 之 
间 的 关系 。 我 们 首先 来 看 抽象 中 介 者 ， 如 代码 清单 33-18 所 示 。 


代码 清单 33-18 抽象 中 介 者 


public abstract class AbsMediator { 

// 工 资 

protected final ISalary salary; 

// 职 位 

protected final IPosition position; 

// 税 收 

protected final ITax tax; 

public AbsMediator(){ 
salary = new Salary(this); 
position = new Position(this); 


tax = new Tax(this); 


有 
// 工 资 增加 了 


public abstract void up(ISalary _salary); 


// 职 位 提升 了 
public abstract 
// 税 收 增加 了 
public abstract 
// 工 资 降低 了 
public abstract 
// 职 位 降低 了 
public abstract 
// 税 收 降低 了 


public abstract 


void 


void 


void 


void 


void 


up(IPosition _position); 
up(ITax _tax); 
down(ISalary _salary); 
down(IPosition _position); 


down(ITax _tax); 


在 抽象 中 介 者 中 我 们 定义 了 6 个 方法 ， 分 别处 理 职位 升降 、 工 资 
降 以 及 税收 升降 的 业务 逻辑 ， 采 用 Java 多 态 机 制 来 实现 ， 我 们 来 看 实现 
类 ， 如 代码 清单 33-19 所 示 。 


代码 清单 33-19 中 介 者 


public class Mediator extends AbsMediator{ 


// 工 资 增加 了 


public void up(ISalary _salary) { 
upSalary(); 


upTax(); 


} 
// 职 位 提升 了 


public void up(IPosition position) { 


upPosition( ); 


upSalary(); 


upTax(); 


站 
// 税 收 增加 了 


public void up(ITax tax) { 


upTax(); 
downSalary( ); 


} 
ys 


* 工 资 、 职 位 、 税 收 降低 的 处 理 方法 相同 ， 不 再 玖 述 
*/ 


// 工 资 增加 


private 


站 


private 


private 


private 


} 


private 
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private 


} 


void upSalary()t{ 
System.out.println(" 工 资 翻 倍 ， 乐 翻天 " ) ， 


void UpTax(){ 
System.out.printLn(" 税 收 上 升 ， 为 国家 做 贡献 " ) ; 


void upPosition()t{ 
System,.out.println(" 职 位 上 升 一 级 ， 狂 喜 " ) ; 


void downSalary(){ 
System.out.println(" 经 济 不 景气 ， 降 低 工资 " ) ; 


void downTax( ){ 
System.out,println(" 税 收 减低 ， 国 家 收入 减少 ")， 


void downPostion( ){ 
System.out.println(" 官 降 三 级 ， 比 自杀 还 痛苦 "); 


该 类 的 方法 较 多 ， 但 是 还 十 非 第 简单 的 ， 它 的 12 个 方法 分 为 两 大 类 
: 一 类 是 每 个 业务 的 独立 流程 ， 比 如 增加 工资 ， 
质 的 职能 ， 而 不 关心 职位 、 税 收 是 如 何 变 化 的 ， 
提供 本 类 内 访问 ， 男 一 类 是 实现 抽象 中 介 者 定义 的 方 
完成 具体 的 每 一 个 逻辑 ， 比 如 职位 上 升 ， 同 时 也 引起 了 工资 增加 、 
税收 增加 。 我 们 编写 一 个 场景 类， 看 看 运行 结 末 ， 如 代码 请 单 33-20 所 


私有 类 型 ， 只 能 


修 ° 


代码 清单 33-20 场景 类 


public class 


Client { 


public static void main(String[] args) { 


// 定 义 中 介 者 
Mediator mediator = new Mediator(); 

// 定 义 各 个 同事 类 

IPosition position = new Position(mediator); 
ISalary Salary = new Salary(mediator ); 


仅仅 实现 单独 增加 工 
该 类 型 的 方法 是 private 


ITax tax = new Tax(mediator ) ， 

// 职 位 提升 了 

System,out .println("=== 职 位 提升 ===" ); 
position.promote( ); 


运行 结果 如 下 所 示 : 
=== 职 位 提升 === 
职位 上 升 一 级 ， 狂 喜 
工资 翻 倍 ， 乐 翻天 


税收 上 升 ， 为 国家 做 贡献 


我 们 回 过 头 来 分 析 一 下 设计 ， 在 接收 到 需求 后 我 们 发 现职 位 、 工 
资 、 税 收 之 间 有 着 紧 密 的 耦合 关系 ， 如 时 不 采 用 中 介 者 模式 ， 则 每 个 对 
象 都 要 与 其 他 两 个 对 象 进行 通信 ， 这 分 必 会 增加 系统 的 复杂 性 ， 同 时 也 
使 系统 处 于 僵化 状态 ， 很 难 实现 拥抱 变化 的 理想 。 通 过 增加 一 个 中 介 
者 ， 每 个 同事 类 的 职位 、 工 唤 、 税 收 都 只 与 中 介 关 通信， 中 介 者 封装 
各 个 同事 类 之 间 的 逻辑 关系 ， 方 便 系统 的 扩展 和 维护 。 


33.2.2 门面 模式 实现 工资 计算 


次 计算 是 一 件 非常 复杂 的 事情 ， 位 单 来 说 ， 它 是 对 基本 工资 、 月 
洋人 金 、 岗 位 津贴 、 绩 效 、 考 勤 、 和 税收、 福利 等 因素 综合 运算 后 的 一 个 数 
字 。 即 使 设计 一 个 HR (人 力 资源 系统， 员工 工资 计算 也 是 非常 复杂 
的 模块 ， 但 是 对 于 外 界 ， 比 如 高 管 层 ， 最 布 望 看 到 的 结 末 是 张 二 拿 了 多 


少 钱 ， 李 四 合 了 多 少 钱 ， 而 不 是 看 中 间 的 计算 过 程 ， 怎 么 计算 那 症 人 事 
部 门 的 事情 。 换 名 话说 ， 对 外 界 的 访问 着 来 说 ， 它 只 要 传递 进去 一 个 人 
员 名 称 和 月 份 即 可 获得 工资 数 ， 而 不 用 关心 其 中 的 计算 有 多 人 么 复杂 ， 这 
束 用 得 上 [门面 模式 了 。 


门面 模式 对 子 系统 起 封装 作用 ， 它 可 以 提供 一 个 统一 的 对 外 服务 接 
口 ， 如 图 33-5 所 示 。 


HRFacade 


+int querySalary(Strng name, Date date) 
+int queryWorkDays(String name) 
、\ 


T 
上 
| | : 


+int getWorkDays() +int totalSalary() 、\ 


Sh 
考勤 


J 


Bonus | Performance BasicSalary 
| 


+int getBonus() +imt getPerformanceValue() +imt getBasicSalary() 


= 下 


图 33-5 HR 系统 的 类 图 


该 类 图 主要 实现 了 工资 计算 ， 通 过 HRFacade| ] 面 可 以 查询 用 户 的 
工资 以 及 出 惑 天 数 等 ， 而 不 用 关心 这 个 工资 或 者 出 勤 天 数 是 怎么 计算 出 


来 的 ， 从 而 屏蔽 了 外 系统 对 工资 计算 模块 的 内 部 细 市 依赖 。 我们 先 看 子 
系统 内 部 的 各 个 实现 ， 考 勤 情 况 如 代码 清单 33-21 所 示 。 


代码 清单 33-21 考勤 情况 


public class Attendance { 
// 得 到 出 勤 天 数 
public int getworkDays(){ 
return (new Random()).nextInt(30); 
} 


非常 测 单 ， 只 用 一 个 方法 获得 一 个 员工 的 出 勤 天 数 。 我 们 再 来 看 奖 
金 计 算 ， 如 代码 清单 33-22 所 示 。 


代码 清单 33-22 奖金 计算 


public class Bonus { 


// 考 勤 情况 
private Attendance atte = new Attendance(); 
// 奖 金 
public int getBonus(){ 
// 获 得 出 勤 情况 
int workDays = atte.getWworkDays( ); 
// 奖 金 计算 模型 


int bonus = workDays * 1800 / 30; 
return bonus; 


我 们 在 这 里 实现 了 一 个 示意 方法 ， 实 际 的 奖金 计算 是 非常 复杂 的 ， 
与 考勤 、 绩 效 、 基 本 工资 、 岗 位 都 有 关系 ,单单 一 个 次 金 计算 就 可 以 设 
计 出 一 个 门面 。 我 们 再 来 看 基本 工资 ， 这 个 基本 上 是 按照 职位 而 定 的 ， 
比较 固定 ， 如 代码 清单 33-23 所 示 。 


代码 清单 33-23 基本 工资 


public class BasicSalary { 
// 获 得 一 个 人 的 基本 工资 
public int getBasicSalary(){ 
return 2000; 
} 


我 们 定义 了 员工 的 基本 工资 都 为 2000 元 ， 没 有 任何 浮动 的 余地 。 表 
来 看 绩效 ， 如 代码 清单 33-24 所 示 。 


代码 清单 33-24 绩效 


public class Performance { 


// 基 本 工资 
private BasicSalary salary = new BasicSalary(); 
// 绩 效 奖励 
public int getPerformanceValue(){ 
// 随 机 绩效 


int perf = (new Random()).nextInt(100); 
return salary.getBasicSsalary() * perf /100; 


绩效 按照 一 个 非常 简单 的 算法 ， 即 基本 工资 乘 以 一 个 随机 的 百 分 
比 。 我 们 再 来 看 税收 ， 如 代码 清单 33-25 所 示 。 


代码 清单 33-25 税收 


public class Tax { 
// 收 取 多 少 税金 
public int getTax(){ 
// 交 纳 一 个 随机 数量 的 税金 
return (new Random()).nextInt(300); 


一 个 计算 员工 薪酬 的 所 有 子 元 素 都 已 经 具备 了 ， 剩 下 的 殉 是 编写 组 
逻辑 类 ， 总 工资 的 计算 如 代码 清单 33-26 所 示 。 


代码 清单 33-26 总 工资 计算 


public class SalaryProvider { 
// 基 本 工资 


private BasicSalary basicSalary = new BasicSalary(); 


private Bonus bonus = new Bonus(); 
// 绩 效 
private Performance perf = new Performance(); 
// 税 收 
private Tax tax = new Tax(); 
// 获 得 用 户 的 总 收入 
public int totalSalary(){ 
return basicSalary.getBasicSalary() + 
bonus.getBonus() + perf.getPperformanceValue() - tax.getTax(); 


} 


里 只 是 对 前 面 的 元 素 值 做 了 一 个 加 减法 计算 ， 这 是 对 实际 HR 系 
统 的 简化 处 理 ， 如 果 把 这 个 类 暴露 给 外 和 系统， 那么 被 修改 的 风险 是 非常 
大 的 ， 因 为 它 的 方法 totalSalary 是 一 个 具体 的 业务 逻辑 。 我 们 采用 门面 
模式 的 目的 是 要 求 门 面 是 无 逻辑 的 ， 与 业务 无 天 ， 只 是 一 个 子 系统 的 访 
问 入 口 。 门 面 模式 只 是 一 个 技术 层次 上 的 实现 ， 全 部 业务 还 是 在 子 系 统 
内 实现 。 我 们 来 看 HR 门面 ， 如 代码 清单 33-27 所 示 。 


代码 清单 33-27 HR 门面 


public class HRFacade { 

// 总 工资 情况 

private SalaryProvider SalaryProvider = new 
SalaryProvider( ); 


// 考 勤 情况 


private Attendance attendance = new Attendance( ) ， 

// 查 询 一 个 人 的 总 收入 

public int querySalary(String name,Date date){ 
return SalaryProvider ,totalSalary( ); 

} 


// 查 询 一 个 员工 一 个 月 工作 了 多 少 天 

public int queryworkDays(String name){ 
return attendance.getWworkDays( ); 

} 


所 有 的 行为 部 是 委托 行为 ， 由 具体 的 于 系统 实现 ， 门 面 只 古 提 供 了 
一 个 统一 访问 的 基础 而 已 ， 不 做 任何 的 校 验 、 判 断 、 异 第 等 处 理 。 我 们 
编写 一 个 场景 类 查看 运行 结 末 ， 如 代码 清单 33-28 所 示 。 


代码 清单 33-28 场景 类 


public class Client { 
public static void main(String[] args) { 
// 定 义 门 面 
HRFacade facade = new HRFacade( ); 
System.out.println("=== 外 系统 查询 总 收入 ===" ) ; 
int salary = facade.querySalary(" 张 三 ", new 


型 


Date(System. 
currentTimeMillis())); 
System.out.println(“" 张 三 11 月 总 收入 为 : " +salary); 
// 再 查询 出 勤 天 数 
System,out.printlLn("NXn=== 外 系统 查询 出 勤 天 数 ===") ， 
int workDays = facade.queryWorkDays(" 李 四 " ) ; 
System.out.printlLn(" 李 四 本 月 出 勤 : " +workDays ) ; 
} 
} 
运行 结果 如 下 所 示 : 
=== 外 系统 查询 总 收入 === 


张 三 11 月 总 收入 为 : 4133 


=== 外 系统 查询 出 勤 天 数 === 


李 四 本 月 出 勤 : 22 


在 该 例 中 ， 我 们 使 用 了 门面 模式 对 薪水 计算 子 系统 进行 封装 ， 避 人 免 
子 系统 内 部 复杂 逻辑 外 汇 ， 确 保 子 系统 的 业务 逻辑 的 蛙 纯 性 ， 即 使 业务 
流程 需要 变更 ， 影 响 的 也 是 子 系统 内 部 功能 ， 比 如 奖金 需要 与 基本 工资 
挂钩 ， 这 样 的 修改 对 外 系统 来 说 是 透明 的 ， 只 需要 子 系统 内 部 变更 即 
可 。 


33.2.3 最 佳 实践 


门面 模式 和 中 介 痢 模式 之 间 的 区 别 还 是 比较 明显 的 ， 门 面 模 式 是 以 
封 丢 和 隔离 为 主要 任务 ， 而 中 介 者 模式 则 是 以 调和 同事 类 之 间 的 关系 为 
主 ， 因 为 要 调和 ， 所 以 具有 了 部 分 的 业务 逻辑 控制 。 两 者 的 主要 区 别 如 
下 : 


e 功能 区 别 


门面 模式 只 是 增加 了 一 个 1 门面， 它 对 于 系统 来 说 没有 增加 任何 的 功 
能 ， 子 系统 各 脱离 门面 模式 是 完全 可 以 独立 运行 的 。 而 中 介 者 模式 则 增 
加 了 业务 功能 ， 它 把 各 个 同事 类 中 的 原 有 耦合 天 系 移植 到 了 中 介 者 ， 同 
事 类 不 可 能 脱离 中 介 者 而 独立 存在 ， 除 非 是 想 增 加 系统 的 复杂 性 和 降低 
扩展 性 。 


e 知晓 状态 不 同 


对 门面 模式 来 说 ， 子 系统 不 知道 有 门面 存在 ， 而 对 中 介 者 来 说 ， 每 
个 同事 类 都 知道 中 介 者 存在 ， 因 为 要 依靠 中 介 者 调和 同事 之 间 的 关系 ， 
它们 对 中 介 者 非常 了 解 。 


e 封 猴 程度 不 同 


门面 模式 是 一 种 稍 单 的 封装 ， 所 有 的 请 求 处 理 都 委托 给 于 系统 完 
成 ， 而 中 介 者 模式 则 需要 有 一 个 中 心 ， 由 中 心 协 调 同事 类 完成 ， 并 且 中 
心 本 映 也 完成 部 分 业务 ， 它 属于 更 进一步 的 业务 功能 封 流 。 


33.3 包 闻 模式 群 PK 


我 们 讲 了 这 么 多 的 设计 模式 ， 大 家 有 没有 发 觉 在 很 多 的 模式 中 有 
些 角 色 是 不 干 活 的 ? 它们 只 是 充当 黔 前 作用 ， 你 有 问题 ， 找 我 ， 但 我 
不 处 理 ， 我 让 其 他 人 处 理 。 最 典型 的 束 是 代理 模式 了 ， 代 理 角 色 接 收 
请 求 然 后 传递 到 被 代理 角色 处 理 。 门 面 模式 也 是 一 样 ， 门 面 角 色 的 任 
务 束 旦 把 请 求 转发 到 子 系统 。 类 似 这 种 结构 的 模式 还 有 很 多 ， 我 们 移 
给 这 种 类 型 的 模式 定义 一 个 名 字 ， 叫 做 包装 模式 (wrapping pattern) 。 
注意 ， 包 装 模 式 是 一 组 模式 而 不 是 一 个 。 包 装 模 式 包括 哪些 设计 模式 
呢 ? 包 疼 模式 包括 : 竣 炳 模式 、 适 配 融 模式 、 门 面 模 式 、 代 理 模式 、 
桥梁 模式 。 下 面 我们 通过 一 组 例子 来 说 明 这 五 个 包 波 模式 的 区 别 。 


33.3.1 代理 模式 


现在 很 多 明星 都 有 经 纪 人 ， 一 般 有 什么 事 他 们 都 会 说 :“ 你 找 我 的 
经 纪 人 谈 好 了 ”， 下 面 我 们 就 看 看 这 一 过 程 起 么 模拟 。 假 设 有 一 个 奶 星 
族 想 找 明 星 签 字 ， 我 们 看 看 采用 代理 模式 怎么 实现 。 代 理 模式 是 包 浪 
模式 中 的 最 一 般 的 实现 ， 类 图 如 图 33-6 所 示 。 


<<mterface>> 
IStar 
F334 


图 33-6 追星 族 找 明星 签字 


类 图 很 简单 ， 就 是 一 个 简单 的 代理 模式 ， 我 们 来 看 明星 的 定义 ， 
明星 接口 如 代码 清单 33-29 所 示 。 


代码 清单 33-29 明星 接口 


public interface IStar { 
// 明 星 都 会 签名 


public void sign(); 


明星 只 有 一 个 行为 : 签字 。 我 们 来 看 明星 的 实现 ， 如 代码 清单 33- 


30 所 示 。 


代码 清单 33-30 明星 


public class Singer implements IStar { 
public void sign() { 
System.out .println(" 明 星 签字 : 我 是 XXX 大 明星 "); 


经 纪 人 与 明星 应 该 有 相同 的 行为 ， 比 如 说 等 名， 虽然 经 纪 人 不 等 
名 ,但 是 他 把 你 要 签名 的 笔记 本 、 衣 服 、CD 等 传递 过 去 让 真正 的 明星 
签 子 ， 经 纪 人 如 代码 清单 33-31 所 示 。 


代码 清音 33-31 经 纪 人 


public class Agent implements IStar { 
// 定 义 是 谁 的 经 纪 人 
private IStar star; 
// 构 造 函 数 传 递 明星 
public Agent(IStar _star)t{ 
this.star = _star; 


} 

// 经 纪 人 是 不 会 签字 的 ， 签 字 了 歌迷 也 不 认 

public void sign() { 
star.sign(); 

} 


应 该 非常 明确 地 指出 一 个 经 纪 人 十 谁 的 代理 ， 因 此 要 在 构造 男 数 
中 接收 一 个 明星 对 象 ， 确 定 是 要 做 这 个 明星 的 代理 。 我 们 再 来 看 看 追 
星 族 是 怎么 找 明 星 签 字 的 ， 如 代码 清香 33-32 所 示 。 


代码 清单 33-32 追星 族 


public class Idolater { 
public static void main(String[] args) { 

// 尘 拜 的 明星 是 谁 
IStar star = new Singer(); 
// 找 到 明星 的 经 纪 人 
IStar agent = new Agent(star); 
System.out.println(" 追 星 族 : 我 是 你 的 崇拜 者 ， 请 答 名 ! ") ; 
// 签 字 
agent .sign(); 


很 简单 ， 找 到 明星 的 代理 ， 然 后 明星 殉 签 宁 了 “。 运 行 结 有 末 如 下 所 


追星 族 :我 是 你 的 崇拜 者 ， 请 签名 ! 
明星 签字 ， 我 是 XXX 大 明星 
真实 签字 的 


看 看 我 们 的 程序 逻辑 ， 我 们 是 找 明星 的 经 纪 人 签字 ， 
是 明星 ， 经 纪 人 只 是 把 这 个 请 求 传递 给 明星 处 理 而 已 ， 这 是 普通 的 代 


理 模式 的 典型 应 用 。 


33.3.2 装饰 模式 


明星 也 都 是 一 步 一 步 地 奋斗 出 来 的 ， 谁 都 不 是 一 步 殉 成 为 大 明星 
演员 通过 粉饰 目 己 给 观众 一 个 好 的 印象 ， 现 在 我 们 就 来 


的 。 甚 至 一 些 演员 ; 
看 怎么 粉饰 一 个 演员 ， 如 图 33-7 所 示 。 


<<Interface>> 
IStar 


+void act() 


-[Star star 


+Decorator(IStar star) 
+vold act() 


EE = 一 3 


+HotAir(IStar star) 
+void act() 


FreakStar 


Deny 


+Deny(IStar star) 
+vold act() 


图 33-7 演技 修饰 


下 面 我 们 就 来 看 看 这 些 过 程 如 何 实现 ， 先 看 明星 接口 ， 如 代码 清 
单 33-33 所 示 。 


代码 清单 33-33 明星 接口 


public interface IStar { 


一 人 


public void act() ; 


我 们 来 看 看 我 们 的 主角 ， 如 代码 清单 33-34 所 示 。 


代码 清单 33-34 假 明 星 


public class FreakStar implements IStar { 
public void act() { 
System.out.println(" 演 中 : 演技 很 抽 劣 " ) ; 
} 


我 们 看 看 这 个 明星 是 怎么 粉饰 的 ， 先 定义 一 个 抽象 装饰 类 ， 
码 清单 33-35 所 示 。 


代码 清单 33-35 抽象 装饰 类 


public abstract class Decorator implements IStar { 
// 粉 饰 的 是 谁 
private IStar star; 
public Decorator(IStar _star)t{ 
this.star = _star; 


} 

public void act() { 
this.star.act(); 

} 


如 代 


前 后 两 次 修饰 ， 开 演 前 毫 无 忌 悦 地 吹 史 ， 如 代码 清单 33-36 所 示 。 


代码 清单 33-36 吹 大 话 


public class HotAir extends Decorator { 
public HotAir(IStar _star)t{ 
super(_star); 


} 
public void act(){ 


System.out.printlLn(" 演 前 : 夸 夸 其 谈 ， 没 有 自己 不 能 演 的 角 


2 


super .act( ); 


大 家 发 现 这 个 明星 演技 不 好 的 时 候 ， 他 拼命 找 借 口 ， 说 是 那天 天 
气 不 好 、 心 情 不 好 等 ， 如 代码 清单 33-37 所 示 。 


代码 清单 33-37 抵赖 


public class Deny extends Decorator { 
public Deny(IStar _star)t{ 
super(_star); 


} 
public void act(){ 
Super .act(); 
System,out,.println(" 演 后 : 百般 抵赖 ， 死 不 承认 ") 


我 们 建立 一 个 场景 把 这 种 情况 展示 一 下 ， 如 代码 清单 33-38 所 示 。 


代码 清单 33-38 场景 


public class Client { 
public static void main(String[] args) { 

// 定 义 出 所 谓 的 明星 
IStar freakStar = new FreakStar(); 
// 看 看 他 是 怎么 粉饰 自己 的 
// 演 前 吹 跨 自己 无 所 不 能 
freakStar = new HotAir(freakSstar); 
// 演 完 后 ， 死 不 承认 自己 演 的 不 好 
freakStar = new Deny(freakStar ) ， 
System,out,.println("==== 看 看 一 些 虚 假 明 星 的 形象 ====") ; 
freakStar .act(); 


运行 结果 如 下 所 示 : 


==== 看 看 一 些 虚假 明星 的 形象 ==== 


演 前 : 专 夸 其 谈 ， 疫 有 上 自己 不 能 演 的 角色 


演 中 : 演技 很 拙劣 


演 后 : 百般 抵赖 ， 死 不 承认 


33.3.3 适配器 模式 


我 们 知道 在 演 乙 轿 中 还 存在 一 种 情况 : 奉 身 ， 蔡 身 也 坪 演 员 ， 只 
征 普 通 的 演员 而 已 ， 在 一 段 戏 中 ， 前 十 五 分 钟 是 明星 本 人 ， 后 十 五 分 
钟 也 是 明星 本 人 ， 束 中 间 的 五 分 钟 是 蔡 映 ， 那 这 个 场景 该 上 怎么 搬 述 
呢 ? 注意 中 间 那 五 分 钟 ， 这 个 时 候 一 个 普通 演员 被 导演 认为 是 明星 演 


员 ， 我 们 来 看 类 图 ， 如 图 33-8 所 示 。 
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图 33-8 替身 演员 类 图 


导演 找 了 一 个 普通 演员 作为 明星 的 奉 号 ， 不 过 观众 看 到 的 还 是 明 
星 的 号 份 。 我 们 来 看 代码 ， 首 先 看 明星 接口 ， 如 代码 清单 33-39 所 示 。 


代码 清单 33-39 明星 接口 


public interface IStar { 
// 明 星 都 要 演戏 
public void act(String context); 


再 来 看 一 个 具体 的 电影 明星 ， 他 的 主要 职责 就 是 演戏 ， 如 代码 清 


单 33-40 所 示 。 


代码 清单 33-40 电影 明星 


public class FilmStar implements IStar { 
public void act(String context) { 
System.out.println(" 明 星 演 戏 : " + context ) ; 


我 们 再 来 看 普通 演员 ， 明 星 束 那么 多 ， 但 是 普通 演员 非常 多 


们 看 其 接口 ， 如 代码 清单 33-41 所 示 。 


代码 清单 33-41 普通 演员 接口 


public interface IActor { 
// 普 通 演员 演戏 
public void playact(String contet); 


的 实 


加 


普通 演员 也 是 演员 ， 有 是 要 演戏 的 ， 我 们 来 看 一 个 普通 演员 
现 ， 如 代码 清单 33-42 所 示 。 


代码 清单 33-42 普通 演员 


public class UnknownActor implements IActor { 
// 普 通 演员 演戏 
public void playact(String context) { 
System.out.println(" 普 通 演员 : "+context )， 
} 


我 们 来 看 奉 身 该 怎么 编写 ， 如 代码 清单 33-43 所 示 。 


代码 清单 33-43 替身 演员 


public class Standin implements IStar { 
private IActor actor ; 


// 蔡 身 是 谁 
public Standin(IActor _actor)t{ 
this.actor = actor; 


public void act(String context) { 
actor .playact(context ) ， 
} 


这 是 一 个 通用 的 替身 ， 哪 个 普通 演员 能 担任 哪个 明星 的 替身 是 由 
导演 决定 的 ， 导 演 想 让 谁 当 就 让 谁 当 ， 我 们 来 看 导演 ， 如 代码 清单 33- 
44 所 示 。 


代码 清单 33-44 导演 类 


public class direcotr { 
public static void main(String[] args) { 
Systenm. out. printlin( 1s====== 演 戏 过 程 费 拟 ==========" ) ， 


// 定 义 一 个 大 明星 
IStar star = new FilmStar(); 

star .act(" 前 十 五 分 钟 ， 明 星 本 人 演戏 ")， 
// 导 演 把 一 个 普通 演员 当做 明星 演员 来 用 
IActor actor = new UnknownActor(); 
IStar standin= new Standin(actor); 
standin.act(" 中 间 五 分 钟 ， 替 身 在 演戏 " ) ; 
star.act(" 后 十 五 分 钟 ， 明 星 本 人 演戏 " ); 


一 


运行 结果 如 下 所 示 : 


明星 演戏 : 前 十 五 分 钟 ， 明 星 本 人 演戏 


山 。 
33.3.4 桥梁 模式 


我 们 继续 说 明星 圈 的 事情 ， 现 在 明星 类 型 太 多 了 ， 比 如 电影 明 
星 、 电 视 明 星 、 歌 星 、 体 育 明 星 、 网 络 明 星 等 ， 每 个 类 型 的 明星 都 有 
明确 的 职 贡 ， 电 影 明 星 的 主要 工作 束 古 演 电 影 ， 电 视 明星 的 主要 工作 
网 


残 生 演 电 视 剧 或 者 主持 电视 节目 。 再 看 看 现在 的 明星 ， 单 一 发 展 的 基 
本 没有 ， 主 持 人 出 专辑 、 体 育 明 星 演 电 影 、 歌 星 拍戏 等 太平 党 了 ， 我 
们 殊 用 程序 来 表现 一 下 多 元 化 情形 ， 如 图 33-9 所 示 。 
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Sn +AbstractStar(AbsAction action) 
+vold doJob() 
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+FilmStar(AbsAction action) +Simger(AbsAction action) 
+vold doJob() +vold doJob() 
图 33-9 各 类 明星 插 述 


图 33-9 中 定义 了 一 个 抽象 明星 AbsStar， 然 后 产生 出 各 个 具体 类 型 
的 明星 ， 比 如 电影 明星 FilmStar、 歌 星 Singer， 当 然 还 可 以 继续 扩展 下 
去 。 这 里 还 定义 了 一 个 抽象 的 行为 AbsAction， 描 述 明 星 所 具有 的 活 
动 ， 比 如 演 电 影 、 唱 歌 等 ， 在 这 种 设计 下 ， 明 星 可 以 扩展 ， 明 星 的 活 


动 也 可 以 扩展 ， 非 常 灵活 。 我 们 移 来 看 明星 的 活动 ， 抽 象 活 动 如 代码 
清单 33-45 所 示 。 


代码 清单 33-45 抽象 活动 


public abstract class AbsAction { 
// 每 个 活动 都 有 描述 
public abstract void desc( ) ， 


很 简单 ， 只 有 一 个 活动 的 描述 ， 由 子 类 来 实现 。 我 们 来 看 演 电 影 
和 唱歌 两 个 活动 ， 分 别 如 代码 清单 33-46、33-47 所 示 。 


代码 清单 33-46 演 电 影 


public class ActFilm extends AbsAction { 


public void desc() { 
System,.out .println(" 演 出 精彩 绝伦 的 电影 " ); 


代码 清单 33-47 唱歌 


public class Sing extends AbsAction { 
public void desc() { 
System.out.println(" 唱 出 优美 的 歌 | 


) ) 


各 种 精彩 的 活动 都 有 了 ， 我 们 再 来 看 抽象 明星 ， 它 是 所 有 明星 的 
代表 ， 如 代码 清单 33-48 所 示 。 


代码 清单 33-48 抽象 明星 


public abstract class AbsStar { 


和 六 
看 电 


// 一 个 明星 参加 哪些 活动 

protected final AbsAction action; 

// 通 过 构造 函数 传递 具体 活动 

public AbsStar (AbstAction _action){ 
this.action = _action; 


} 

// 每 个 明星 都 有 自己 的 主要 工作 

public void doJob(){ 
action.desc( ); 

} 


明星 都 有 自己 的 主要 活动 (或 者 是 主要 工作 ) ， 我 们 在 抽象 明星 
\ 是 定义 明星 有 活动 ， 具 体 有 什么 活动 由 各 个 于 类 实现 。 我 们 再 来 
影 明 星 ， 如 代码 清香 33-49 所 示 。 


代码 清单 33-49 电影 明星 


public class FilmStar extends AbsStar { 


// 上 默认 的 电影 明星 的 主要 工作 是 拍 电影 
public FilmStar()t{ 
super (new ActFilm( )); 


} 

// 也 可 以 重新 设置 一 个 新 职业 

public FilmStar(AbsAction _action)t{ 
super(_action); 


} 

// 细 化 电影 明星 的 职责 

public void doJob(){ 
System.out .println("\n====== 有 影星 的 工作 =====" )， 
super .doJob( ); 


电影 明星 的 本 职工 作 束 应 该 是 演 电 影 ， 因 此 束 有 了 一 个 无 参 构造 


函数 来 定义 电影 明星 的 默认 工作 ， 如 采 明 星 要 客串 一 下 去 唱歌 也 可 


以 ， 有 参 构 造 解 决 了 该 问题 。 歌 星 的 实现 与 此 相同 ， 如 代码 清单 33-50 
操守 


代码 清单 33-50 歌星 


public class Singer extends AbsStar { 
// 歌 星 的 默认 活动 是 唱歌 
public Singer(){ 
super (new Sing()); 


} 

// 也 可 以 重新 设置 一 个 新 职业 

public Singer (AbsAction _action)t{ 
super(_action); 


} 

// 细 化 歌星 的 职责 

public void doJob(){ 
System,out,println("NXn====== 歌 星 的 工作 =====" ); 
Super .doJob(); 


我 们 使 用 电影 明星 和 歌星 来 作为 代表 ， 这 两 类 明星 也 是 我 们 经 党 
听 到 或 看 到 的 ， 下 面 建立 一 个 场景 类 来 模拟 一 下 明星 的 事迹 ， 如 代码 
清单 33-51 所 示 。 


代码 清单 33-51 场景 


public class Client { 

public static void main(String[] args) { 
// 声 明 一 个 电影 明星 
AbsStar zhangSan = new FilmStar(); 
// 声 明 一 个 歌星 
AbsStar liSi = new Singer(); 
// 展 示 一 下 各 个 明星 的 主要 工作 
zhangSan.doJob(); 
1iSi.doJob(); 
// 当 然 ， 也 有 部 分 明星 不 务 正业 ， 比 如 歌星 演戏 
liSi = new Singer(new ActFilm()); 


1iSi.doJob(); 


运行 结果 如 下 所 示 : 


====== 影 时 的 作 ===== 


演出 精彩 绝伦 的 电影 


====== 歌 星 的 工作 ===== 


唱 出 优美 的 歌 


====== 歌 星 的 工作 ===== 


演出 精彩 绝伦 的 电影 


好 了 ， 各 类 明星 都 有 目 己 的 本 职工 作 ， 但 是 偶尔 客串 一 个 其 他 类 
型 的 活动 也 是 允许 的 ， 如 此 设计 后 ， 明 星 束 可 以 不 用 固定 在 目 己 的 本 
职工 作 上 ， 而 古 向 其 他 方向 发 展 ， 比 如 影视 歌 三 栖 明 星 。 


门面 模式 我 们 在 其 他 章节 已 经 讲解 得 比较 多 了 ， 本 小 世 就 不 再 痪 


了 述 。 


33.3.5 最 佳 实践 


5 个 包 帮 模式 是 大 家 在 系统 设计 中 经 芝 会 用 到 的 模式 ， 它 们 有 具 有 相 
似 的 特征 : 都 是 通过 委托 的 方式 对 一 个 对 象 或 一 系列 对 象 《例如 门面 
模式 ) 施行 包装 ， 有 了 包装 ， 设 计 的 系统 才 更 加 灵活 、 稳 定 ， 并 且 极 


具 扩 展 性 。 从 实现 的 角度 来 看 ， 它 们 都 是 代理 的 一 种 具体 表现 形式 ， 
我 们 来 看 看 它们 在 使 用 场景 上 有 什么 区 别 。 


代理 模式 主要 用 在 不 希望 展示 一 个 对 象 内 部 细 市 的 场景 中 ， 比 如 
一 个 远程 服务 不 需要 把 远程 连接 的 所 有 细 市 都 歇 露 给 外 部 模块 ， 通 过 
增加 一 个 代理 类 ， 可 以 很 轻松 地 实现 被 代理 类 的 功能 封装 。 此 外 ， 代 
理 模式 还 可 以 用 在 一 个 对 象 的 访问 需要 限制 的 场景 中 ， 比 如 AOP 。 


痛 炳 模式 是 一 种 特殊 的 代理 模式 ， 它 倡导 的 是 在 不 改变 接口 的 前 
提 下 为 对 象 增 强 功 能 ， 或 者 动态 添加 额外 职责 。 束 扩展 性 而 言 ， 它 比 
子 类 更 加 灵活 ， 例 如 在 一 个 已 经 运行 的 项 目 中 ， 可 以 很 轻松 地 通过 增 
加 天 饰 类 来 扩展 系统 的 功能 。 


适配器 模式 的 主要 意图 是 接口 转换 ， 把 一 个 对 象 的 接口 转换 成 系 
统 希 望 的 另外 一 个 接口 ， 这 里 的 系统 指 的 不 仅仅 是 一 个 应 用 ， 也 可 能 
征 某 个 环境 ， 比 如 通过 接口 转换 可 以 屏蔽 外 办 接口 ， 以 免 外 界 接 口 深 
入 系统 内 部 ， 从 而 提高 系统 的 稳定 性 和 可 靠 性 。 


桥 染 模式 是 在 抽象 层 产 生 耦 合 ， 解 决 的 是 自行 扩展 的 问题 ， 它 可 
以 使 两 个 有 耦合 关系 的 对 象 互 不 影响 地 扩展 ， 比 如 对 于 使 用 笔画 图 这 
样 的 需求 ， 可 以 采用 桥梁 模式 设计 成 用 什么 笔 (铅笔 、 毛 笔画 什么 
图 ( 圆 形 、 方 形 ) 的 方案 ， 至 于 以 后 需求 的 变更 ， 如 增加 笔 的 类 型 ， 
增加 图 形 等 ， 对 该 设计 来 说 是 小 荣 一 碟 。 


门面 模式 是 一 个 粗 粒 度 的 封装 ， 它 提供 一 个 方便 访问 子 系统 的 接 
口 ， 不 具有 任何 的 业务 逻辑 ， 仅 仅 是 一 个 访问 复杂 系统 的 快速 通道 ， 
没有 它 ， 子 系统 照样 运行 ， 有 了 它 ， 只 是 更 方便 访问 而 已 。 
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一 一 设计 模式 混 编 
命令 模式 + 责任 链 模式 
工厂 方法 模式 + 策略 模式 
观察 者 模式 + 中 介 者 模式 


第 34 章 ”命令 模式 + 贡 任 链 模 式 


34.1 搬移 UNIX 的 命令 


在 操作 系统 的 世界 里 ， 有 了 两 大 阵 宫 一 直 在 PK 着 : *nix (包括 UNIX 
和 Linux) 和 Windows。 从 目前 的 统计 数据 来 看 ，*nix 在 应 用 服务 器 领 
域 占 据 相 对 优势 ， 不 过 Windows 也 不 甘 示 弱 ， 国 内 某 些 小 型 银行 已 经 在 
使 用 PC Server (安装 Windows 操 作 系 统 的 服务 器 ) 集群 来 进行 银行 业务 
运算 ， 而且 稳定 性 、 性 能 各 方面 的 效 琳 不错; 而 在 个 人 桌面 方面 ， 
Windows 是 占 绝对 优势 的 ， 大 家 应 该 基本 上 部 在 用 这 个 操作 系统 ， 它 的 
诸多 优点 这 里 束 不 多 说 了 ， 我 们 今天 束 来 解决 一 个 习惯 问题 。 如 果 你 
负责 过 UNIX 系 统 维护 ， 你 目 己 的 笔记 本 又 是 Windows 操 作 系统 的 话 ， 
我 想 你 肯定 有 这 样 的 经 验 ， 如 图 34-1 所 示 。 


: Documents and Settings dministrator>1s 
'1s， 不 是 内 部 或 外 部 命令 ， 也 不 是 可 运行 的 程序 
或 批 处 理 艾 件 。 


: DocumentsS and Settings ‘Administrator>ls 一 1a 


"1s， 不 是 内 部 或 外 部 命令 ， 也 不 是 可 运行 的 程序 


或 批 处 理 文件 。 


ITHT TT Settings\Adninistrator>11 
'11 不 是 内 部 或 外 部 命令 ， 世 不 是 可 运行 的 寿 序 
或 批 处 理 文件 。 


:Documents and Settings dninistrator> 


图 34-1 时 和 常 犯 的 错误 


是 不 是 经 常 把 UNIX 上 的 命令 裔 到 Windows 系 统 了 ? 为 了 避免 这 种 
情况 发 生 ， 可 以 把 UNIX 上 的 命令 移植 到 Windows 上 ， 也 就 是 Windows 
下 的 shell 工 具 ， 有 很 多 类 似 的 工具 ， 比 如 cygwin、GUN Bash 等 ， 这 些 
都 是 非常 完美 的 工具 ， 我 们 今天 的 任务 就 是 自己 写 一 个 这 样 的 工具 。 
怎么 写 呢 ? 我们 学 了 这 么 多 的 模式 ， 当 然 要 融会 贯通 了 ， 可 以 使 用 命 
令 模式 、 责 任 链 模式 、 模 板 方 法 模式 设计 一 个 方便 扩展 、 稳 定 的 工 


O 
~ 


S 


我 们 先 说 说 UNIX 下 的 命令 ， 一 条 命令 分 为 命令 名 、 远 项 和 操作 
数 ， 例 如 命令 "ls-lusr"， 其 中 ，1ls 是 命令 名 ，] 是 选项 ，/usr 征 操作 数 ， 
后 两 项 都 是 可 选项 ， 根 据 实际 情况 而 定 。UNIX 命 令 一 定 遵守 以 下 儿 个 
规则 : 


。 命令 名 为 小 写字 母 。 


e 命 分 名 、 这 项、 操作 数 之 间 以 空格 分 隅 ， 空 格 数 量 不 受 限 制 。 


e 选项 之 间 可 以 组 合 使 用 ， 也 可 以 单独 拆 分 使 用 。 


e 选项 以 横 杠 (-) 开头 。 


在 UNIX 世 界 中， 我 们 最 利用 的 束 生 ls 这 个 命令 ， 它 用 于 显示 目录 
或 文件 信息 ， 下 面 我 们 爷 来 看 看 这 个 命令 。 币 用 的 有 以 下 几 条 组 合 命 


e1s: 人 简单 列 出 一 个 目录 下 的 文件 。 


e 1s-1: 详细 列 出 目录 下 的 文件 。 


e ls-a: 列 出 目录 下 包含 的 隐藏 文件 ， 主 要 是 点 号 (.) 开头 的 文 


e ls-s: 列 出 文件 的 大 小 。 


除 此 之 外 ， 还 有 一 些 非 常常 用 的 组 合 命 令 ， 如 "ls-la"、"]s-ls" 等 。]s 
命令 名 确定 了 ， 但 是 其 后 连接 的 选项 和 操作 数 是 不 确定 的 。 操 作 数 我 
们 不 用 关心 它 ， 每 个 命令 必然 有 一 个 操作 数 ， 夺 没有 则 是 当前 的 目 
孙 。 问 题 的 关键 是 选项 ， 用 哪个 选项 以 及 什么 时 候 使 用 都 是 由 用 户 决 
定 的 ， 也 就 是 从 设计 上 考虑 。 设 计 者 需要 完全 解析 所 有 的 参数 ， 需 要 


很 多 个 类 来 处 理 如 此 多 的 选项 ， 客 户 输入 一 个 参数 ， 立 刻 返 回 一 个 结 
果 。 和 针对 一 个 ]s 命 令 族 ， 要 求 如 下 : 

e 每 一 个 ls 命令 都 有 操作 数 ， 默 认 操 作 数 为 当前 目 隶 。 

e 选项 不 可 重复 ， 例 如 对 于 "ls-1-l-s"， 解 析出 的 选项 应 该 只 有 两 
A ] 选 项 和 s 选 项 了 

e 每 个 选项 返回 不 同 的 结果 ， 也 残 是 说 每 个 选项 应 该 由 不 同 的 业务 
逻辑 来 处 理 。 

e 为 提高 扩展 性 ，ls 命 令 族 内 的 运算 应 该 是 对 外 封闭 的 ， 减 少 外 界 
访问 ls 命令 族 内 部 细节 的 可 能 性 。 

针对 一 个 命令 族 的 分 析 结 果 ， 我 们 可 以 使 用 什么 模式 ? 责任 链 模 
式 ! 对 ， 只 要 把 一 个 参数 传递 到 链 首 ， 就 可 以 立刻 获得 一 个 结果 ， 中 


间 是 如 何 传递 的 以 及 由 哪个 逻辑 解析 都 不 需要 外 界 (高 层 ) 模块 关 
心 ， 该 模块 的 类 图 如 图 34-2 所 示 。 


CommandName 


+final Strng handle Message(CommandVO vo) 
+vold setNext(CommandName operator) 
+String getOperateParam() 
+String echo(CommandVO vo) 


负责 组 装 k 命 令 链 


所 有 命令 的 老 祖宗 、 


a 人 全 地 : Sy 


图 34-2 命令 族 的 解析 类 图 


类 图 还 是 比较 清晰 的 ，UNIX 的 命令 有 上 百 个 ， 我 们 定义 一 个 
CommandName 抽 象 类 ， 所 有 的 命令 都 继承 于 该 类 ， 它 就 是 责任 链 模式 
的 handler 类 ， 负 责 链 表 控 制 ， 每 个 命令 族 都 有 一 个 独立 的 抽象 类 ， 因 
为 每 个 命令 族 都 有 其 独特 的 个 性 ， 比 如 ls 命令 和 df 命令 ， 其 后 可 加 的 参 
数 是 不 一 样 的 ， 这 就 可 以 在 抽象 类 AbstractLS 中 定义 ， 而 且 它 还 有 标示 
作用 ， 标 示 其 下 的 实现 类 都 是 实现 ls 命令 的 ， 只 是 命令 的 选项 不 同 ; 
Context 负 责 建立 一 条 命令 的 链表 ， 比 如 ls 命令 族 、df 命 令 族 等 ， 它 组 闭 
出 一 个 处 理 一 个 命令 族 的 责任 链 ， 并 返回 首 节点 供 高 层 模块 调用 ， 

是 非常 典型 的 责任 链 模式 。 


分 析 完 毕 一 个 具体 的 命令 族 ， 已 经 确定 可 以 采用 责任 链 模式 ， 我 
们 继续 往 下 分 析 。UNIX 命 令 非常 多 ， 敲 一 个 命令 返回 一 个 结果 ， 每 个 
具体 的 命令 可 以 由 相关 的 命令 族 (也 就 是 责任 链 ) 来 解析 ， 但 是 如 此 
多 的 命令 还 是 需要 有 一 个 派发 的 角色 ， 输 入 一 个 命令 ,不 管 后 台 谁 来 
解析 ， 返 回 一 个 结果 束 成 ， 这 就 要 用 到 命令 模式 。 命 令 模式 人 负责 协调 
各 个 命令 正确 地 传递 到 各 个 责任 链 的 首 节点 ， 这 就 是 它 的 任务 ， 其 类 
图 如 图 34-3 所 示 。 


| 


+String execute(CommandVO vo) 
| #final List buildCham(Class abstractClass) 


命令 解析 的 责任 链 ， 并 调用 链 的 首 


图 34-3 命令 传递 类 图 


古人 不 是 典型 的 命令 模式 类 图 ? 其 中 Chain 是 一 个 标示 符 ， 表 示 的 束 
年 我 们 上 面 分 析 的 贡 任 链 ， 每 一 个 具体 的 命令 负责 调用 贡 任 链 的 首 节 
点 ， 获 得 返回 值 ， 结 束 命 令 的 执行 。 两 个 核心 模块 都 分 析 完 毕 了 ， 就 
可 以 把 类 图 融合 在 一 起 ， 完 整 的 类 图 如 图 34-4 所 示 。 


这 个 类 图 还 是 比较 商 单 的 ， 我 们 来 看 一 下 各 个 类 的 职责 。 


© ClassUtils 


ClassUtils 是 工具 类 ， 其 主要 职 贡 是 根据 一 个 接口 、 父 类 查找 到 所 
有 的 子 类 。 在 不 考虑 效率 的 应 用 中 ， 使 用 该 类 可 以 市 来 非常 好 的 扩展 
全 二 


e CommandVO 
CommandVO 是 命令 的 值 对 象 ， 它 把 一 个 命令 解析 为 命令 名 、 选 


项 、 操 作 数 ， 例 如 "ls-yusr" 命 令 分 别 解析 为 getCommandName、 


getParam、getData 三 个 方法 的 返回 值 。 
e CommandEnum 


CommandEnum 是 枚 举 类 型 ， 征 主要 的 命令 配置 文件 。 为 什么 需要 
枚 举 类 型 ? 这 是 JDK 1.5 提 供 的 一 个 非常 好 的 功能 ， 我 们 在 程序 中 再 讲 
解 如 何 使 用 它 。 


所 有 的 分 析 都 已 经 完成 了 ， 我 们 来 看 看 程序 。 程 序 不 复杂 ， 看 看 
类 图 ， 应 该 先 写 命令 的 解释 ， 这 是 项 目的 核心 。 我 们 先 来 看 
CommandName 抽 象 类 ， 如 代码 清单 34-1 所 示 。 


<<enumeration>> 


2 


= 
+String exec(Strng commandStr) 


Y 


Command 
ce = 
+Siring execute(CommandVO vo) 

#final List buildCham(Class abstractClass) 


CommandEnum 


Class Utils 


LSCommand 


ea 
+final Strng handleMessage(CommandVO vo) 
+voild setNext(CommandName _operator) 
+String getOperateParaml() 
+String echo(CommandVO vo) 


CommandVO 


图 34-4 完整 类 图 


代码 清单 34-1 抽象 命令 名 类 


public abstract class CommandName { 
private CommandName nextOoperator 
public final String handleMessage(CommandVO vo)t{ 
// 处 理 结果 
String result = ""， 
// 判 断 是 否 是 自己 处 理 的 参数 


if(vo.getParam().size() == 0 || 
vo.getParam().contains (this.getoperateParam( ) ) ){ 
result = this.echo(vo); 


}elsef{ 
if(this.nextOperator !=null)t{ 
result = 
this.nextOperator.handleMessage(vo); 
}elsef{f 
result = "命令 无 法 执行 "， 
} 
} 


return result; 


} 

// 设 置 剩 余 参数 由 谁 来 处 理 

public void setNext(CommandName _operator ){ 
this.nextOperator = _operator ; 


} 

// 每 个 处 理 者 都 要 处 理 一 个 后 缀 参数 

protected abstract String getoperateParam( ) ; 
// 每 个 处 理 者 都 必须 实现 处 理 任 务 

protected abstract String echo(CommandVO vo); 


很 简单 ， 就 是 责任 链 模式 中 的 handler， 也 就 是 中 挖 程序 ， 控 制 一 
个 链 应 该 如 何 建立 。 我 们 再 来 看 3 个 ls 命令 族 ， 先 看 AbstractLS 抽 象 类 ， 
如 代码 清单 34-2 所 示 。 

代码 清单 34-2 抽象 ls 命令 


public abstract class AbstractLS extends CommandNamef{ 


// 默 认 参 数 

public final static String DEFAULT_PARAM = "”"; 
// 参 数 a 

public final static String A_ PARAM ="a"; 

// 参 数 1 


public final static String L_PARAM = "1"; 


很 惊讶 ， 是 吗 ? 怎么 是 个 空 的 抽象 类 ? 是 的 ， 确 实 是 一 个 空 类 ， 
只 定义 了 3 个 参数 名 称 ， 它 有 两 个 职 贡 : 


e 标记 ls 命令 族 。 


e 个 性 化 处 理 。 


因为 现在 还 没有 思考 清楚 18 有 什么 个 性 (可 以 把 命令 的 选项 也 认为 
是 其 个 性 化 数据 /) ， 所 以 先 写 个 空 类 放 在 这 里 ， 以 后 想 清 楚 了 再 填写 
上 去 ， 留 下 一 些 可 扩展 的 类 也 许 会 给 未 来 这 来 不 可 估量 的 优点 。 


我 们 再 来 看 ls 不 市 任何 参数 的 命令 处 理 ， 如 代码 清单 34-3 所 示 。 


代码 清单 34-3 ls 命令 
public class LS extends AbstractLS { 
// 最 简单 的 ls 命令 
protected String echo(CommandVO vo) { 
return FileManager.1ls(vo.formatData( )); 


} 

// 参 数 为 空 

protected String getoperateParam( ) { 
return Super .DEFAULT_PARAM ， 

} 


太 简单 了 ， 首 先 定义 了 自己 能 处 理 什么 样 的 参数 ， 即 只 能 处 理 不 
带 参 数 的 ls 命令 ，getOperateParam 返 回 一 个 长 度 为 零 的 字符 串 ， 就 是 说 
该 类 作为 链 上 的 一 个 节点 ， 只 处 理 没有 参数 的 ls 命令 。echo 方 法 是 执行 
ls 命令 ， 通 过 调用 操作 系统 相关 的 命令 返回 结果 。 我 们 再 来 看 ls -] 命 
令 ， 如 代码 消音 34-4 所 示 。 


代码 清单 34-4 1s-] 命 令 


public class LS_L extends AbstractLS { 
protected String echo(CommandVO vo) { 
return FileManager.1s_l1(vo.formatData( )); 
} 
//1 选 项 
protected String getOperateparam() { 
return super.L_ PARAM; 
} 


该 类 只 处 理 远 项 为 "1" 的 命令 ， 也 非常 们 单 。1s-a 命 令 的 处 理 与 此 类 
似 ， 如 代码 清单 34-5 所 示 。 


代码 清单 34-5 ls-a 命 令 
public class LS_A extends AbstractLS { 
//ls -a 命令 
protected String echo(CommandVO vo) { 
return FileManager.1s al(vo.formatData( )); 


protected String getOperateparam() { 
return super.A_ PARAM; 
} 


这 3 个 实现 类 都 关联 到 了 FileManager， 这 个 类 有 什么 用 呢 ? 它 是 负 
责 与 操作 系统 交互 的 。 要 把 UNIX 的 命令 迁移 到 Windows 上 运行 ， 就 需 
要 调用 Windows 的 低层 男 数 ， 实 现 起 来 较 复 杂 ， 而 且 和 我 们 本 章 要 讲 的 
内 容 没 有 太 大 关系 ， 所 以 这 里 采用 示例 性 代码 代 奉 ， 如 代码 清单 34-6 所 


修 ° 


代码 清单 34-6 文件 管理 类 


public class FileManager { 
//l1s 命 令 
public static String ls(String path)t{ 


return "filelxnfile2Nxnflile3NXnfile4"; 


} 
//ls -1 命令 
public static String 1s_l1(String path)t{ 
String str = "drw-rw-rw root system 1024 2009-8-20 
10:23 filei\n"; 
str = str + "drw-rw-rw root system 1024 2009-8-20 
10:23 file2\n"; 
str = str + "drw-rw-rw root system 1024 2009-8-20 
10:23 file3"; 
return str; 


//ls -a 命令 

public static String ls_a(String path)t{ 
String str = ".\n..\nfilei\nfile2\nfile3"; 
return str; 


以 上 都 是 比较 简单 的 方法 ， 大 家 有 兴趣 可 以 目 己 实现 一 下 ， 以 下 
提供 3 种 思路 : 


e 通过 java.io.File 类 目 己 封装 出 类 似 UNIX 的 返回 格式 。 


e 通过 java.lang.Runtime 类 的 exec 方 法 执行 dos 的 dir 命 令 ， 产 生 类 似 
的 ls 结 采 。 


e 通过 JNI (Java Native Interface) 来 调用 与 操作 系统 有 关 的 动态 链 
接 库 ， 当 然 前 提 是 需要 目 己 写 一 个 动态 链接 库 文 件 。 


3 个 具体 的 命令 都 已 经 解析 完毕 ， 我 们 再 来 看 看 如 何 建立 一 条 处 理 
由 于 建 链 的 任务 已 经 移植 到 抽象 命令 类 ， 我 们 就 完 来 看 抽象 类 
Command， 如 代码 清单 34-7 所 示 。 


代码 清单 34-7 抽象 命令 


public abstract class Command { 
public abstract String execute(CommandVO vo); 
// 建 立 链表 
protected final List<? extends CommandName> 
buildChain(Class<? extends CommandName> abstractClass ){ 
// 取 出 所 有 的 命令 名 下 的 子 类 
List<Class> classes = 
人 
// 存 放 命 令 的 实例 ， 并 建立 链表 关系 
List<CommandName> commandNameList = new 
ArrayList<CommandName>( ) ， 
for(Class c:classes)t{ 
CommandName commandName =null; 


try { 


// 产 生 实 例 
commandName = 
(CommandName )Class.forName (c.getName()) ,newInstance() ; 
} catch (Exception e){ 
// TODO 异常 处 理 
} 


// 建 立 链表 
if(commandNameList.size()>0)t{ 


commandNameList.get(commandNameList.size()-1).setNext 
(commandName ) ; 
} 


commandNameList.add(commandNanme ) ; 


return commandNameList,; 


一 


Command 抽 象 类 有 两 个 作用 : 一 是 定义 命令 的 执行 方法 ， 二 是 人 负 
责 命令 族 (责任 链 ) 的 建立 。 其 中 buildChain 方 法 负责 建立 一 个 责任 
链 ， 它 通过 接收 一 个 抽象 的 命令 族 类 就 可 以 建立 一 条 命令 解析 链 ， 如 
传递 AbstarctLS 类 束 可 以 建立 一 条 解析 1s 命 令 族 的 责任 链 ， 请 读者 注意 
如 下 这 人 句 代 码 : 


commandName = 
(CommandName )ClLlass.forName(c.getName()).newInstance( ); 


在 一 个 遍历 中 ， 类 中 的 每 个 元 素 都 是 一 个 类 名 ， 然 后 根据 类 名 产 
一 个 实例 ， 它 会 抛 出 异 前 ， 例 如 类 文件 不 存在 、 初 始 化 失败 等 ， 读 
者 在 设计 时 要 实现 该 部 分 的 异 湄 。 我 们 再 来 想 一 下 ， 每 个 实现 类 的 类 
名 是 如 何 取 得 的 呢 ? 看 下 面 这 人 句 代 码 : 


List<Class> classes = ClassUtils.getSonClass(abstractClass); 


根据 一 个 父 类 取得 所 有 子 类 ， 是 一 个 非常 好 的 工具 类 ， 其 实现 如 
代码 清单 34-8 所 示 。 


代码 清单 34-8 根据 父 类 获得 子 类 


public class ClassUtils { 
// 根 据 父 类 查找 到 所 有 的 子 类 ， 默 认 情 况 是 子 类 和 父 类 都 在 同一 个 包 名 下 
public static List<Class> getSonclass(Class fatherClass)t{ 
// 定 义 一 个 返回 值 
List<Class> returnClassList = new ArrayList<Class>(); 
// 获 得 包 名 称 
String packageName = 
fatherClass.getPackage().getName(); 
// 获 得 包 中 的 所 有 类 
List<Class> packClasses = getClasses(packageName ) ， 
// 判 断 是 否 是 子 类 
for(Class c:packClasses)t{ 
if(fatherClass.isAssignableFrom(c) && 
!fathercClass.equals(c))t{ 
returnClassList.add(c); 
} 
} 


return returnClassList,; 


} 
// 从 一 个 包 中 查找 出 所 有 的 类 ， 在 jar 包 中 不 能 查找 
private static List<Class> getClasses(String packageName) { 
ClassLoader classLoader = Thread.currentThread() 
.getContextClassLoader( ); 
String path = packageName.replace('.', '/'); 


Enumeration<URL> resources = null; 
try { 
resources = classLoader .getResources(path); 
} catch (IOException e) { 
// TODO Auto-generated catch block 
e.printStackTrace( ); 
} 
List<File> dirs = new ArrayList<File>(); 
while (resources.hasMoreElements()) { 
URL resource = resources.nextElement(); 
dirs.add(new File(resource.getFile())); 


ArrayList<Class> classes = new ArrayList<Class>(); 
for (File directory : dirs) { 
classes.addAll(findClasses(directory, 
packageName ) ) ; 


return classes; 
} 
private static List<Class> findClasses(File directory, 
String packageName) { 
List<Class> classes = new ArrayList<Class>(); 
If (!'directory.exists()) { 
return classes; 


} 
File[] files = directory.1listFiles(); 
for (File file : files) { 
If (file.isDirectory()) { 
assert !file.getName().contains("."); 
classes.addAll(findCclasses(file, packageName + 
"." + file.getName( ))); 
} else if (file.getName().endswith(".class")) { 
try 
classes.add(Class.forName(packageName + '.' + 
file.getName() .substring(©0, file.getName().length() - 6))); 
} catch (ClassNotFoundException e) { 
e.printStackTrace( ); 
} 


} 
} 


return classes; 


这 个 类 请 大 家 谨慎 使 用 ， 在 核心 的 应 用 中 尽量 不 要 使 用 该 工具 ， 


青 
它 会 严重 影响 性 能 。 
再 来 看 LSCommand 类 的 实现 ， 如 代码 清单 34-9 所 示 。 


代码 清单 34-9 具体 的 ls 命令 


public class LSCommand extends Command{ 
public String execute(CommandVO vo){ 
// 返 回 链表 的 首届 点 
CommandName firstNode = 
super.buildCchain(AbstractLSs.class).get(0); 
return firstNode.handleMessage(vo); 
} 


很 简单 的 方法 ， 先 建立 一 个 命令 族 的 责任 链 ， 然 后 找到 首 方 点 调 
用 。 在 该 类 中 我 们 使 用 CommandVO 类 ， 它 是 一 个 封装 对 象 ， 其 代码 如 
代码 清单 34-10 所 示 。 


代码 清单 34-10 命令 对 象 


public class CommandVoO { 
// 定 义 参 数 名 与 参数 的 分 隔 符 号 , 一般 是 空格 
public final static String DIVIDE_FLAG =" "; 
// 定 义 参 数 前 的 符号 ，Unix 一 般 是 - ,如 1s -la 
public final static String PREFIX="-"; 
// 命 令 名 ， 如 1s、du 


private String commandName = ""; 

// 人 参数 列表 

private ArrayList<String> paramList = new ArrayList<String> 
(); 

// 操 作 数 列表 


private ArrayList<String> dataList = new ArrayList<String> 


// 通 过 构造 函数 传递 进来 命令 
public CommandVO(String commandStr)t{ 


(); 


// 负 规 判 断 
if(commandSstr != null && commandStr .Jength() !=0){ 
// 根 据 分 隅 符号 拆 分 出 执行 符号 
String[] complexStr = 
commandSstr .split(CommandVO.DIVIDE_ FLAG); 
// 第 一 个 参数 是 执行 符号 
this.commandName = complexStr[0]; 
// 把 参数 放 到 List 中 
for(int i=1;i<complexStr.1length;i++)t{ 
String str = complexStr[i]; 
// 包 含 前 缀 符号 ， 认 为 是 参 交 


if(str.indexOof (CommandVO.PREFIX)==0){ 
this.paramList.add(str.replace 
(CommandVO .PREFIX, "").trim()); 
}elsef{ 


this.dataList.add(str.trim()); 
} 


}elsef{ 
// 传 递 的 命令 错误 
System.out.println(" 命 令 解析 失败 ， 必 须 传递 一 个 命 
令 才 能 执行 !")， 


} 

// 得 到 命令 名 

public String getCommandName( ){ 
return this.commandName; 


} 
// 获 得 参数 
public ArrayList<String> getParam( ){ 
// 为 了 方便 处 理 空 参数 
if(this.paramList.size() ==0){ 
this.paramList.add(""); 


return new ArrayList(new HashSset(this.paramList)); 


} 

// 获 得 操作 数 

public ArrayList<String> getData( ){ 
return this.dataList; 

} 


CommandVO 解 析 一 个 命令 ， 规 定 一 个 命令 必须 有 3 项 : 命令 名 、 
选项 、 操 作 数 。 如 果 没 有 呢 ? 那 就 以 长 度 为 零 的 字符 串 代 替 ， 通 过 这 
样 的 一 个 约定 可 以 大 大 降低 命令 解析 的 开发 工作 。 注 意 getParam 参 数 中 
的 返回 值 : 


new ArrayList(new HashSet(this.paramList)); 


为 什么 要 这 么 处 理 ? HashSet 共 有 值 唯一 的 优点 ， 这 样 处 理 束 是 为 
了 避免 出 现 两 个 相同 的 参数 ， 比 如 对 于 "ls-l-1-s" 这 样 的 命令 ， 通 过 


getParam 返 回 的 参数 是 儿 个 呢 ? 回答 是 两 个 : 1] 选项 和 s 选 项 。 


我 们 再 来 看 Invoker 类 ， 和 是 负责 命令 分 发 的 类 ， 如 代码 清单 34-11 
RS 


代码 清单 34-11 命令 分 发 


public class Invoker { 

// 执 行 命令 

public String exec(String _commandStr){ 
// 定 义 返 回 值 
String result = ""， 
// 首 先 解析 命令 
CommandVO vo = new CommandVO(_commandSstr ) ， 
// 检 查 是 否 文 持 该 命令 


if(CommandEnum.getNames().contains(vo.getCommandName()))t{ 
// 产 生命 令 对 象 
String className = CommandEnum.valueoOf 
(vo.getCcommandName()) .getvalue(); 
Command command; 
try { 
command = 
(Command)Class.forName(className).newInstance( ); 
result = command.execute(vo); 
}catch(Exception e)t{ 


// TODO 异常 处 理 


} 
}elsef 
result = "无 法 执行 命令 ， 请 检查 命令 格式 " 
} 
return result,; 
} 
} 
实现 也 是 比较 简单 的 ， 从 CommandEnum 中 获得 命令 与 命令 类 的 配 
置信 息 ， 然 后 建立 一 个 命令 实例 ， 调 用 其 execute 方 法 ， 完 成 命令 的 执 


行 操作 。CommandEnum 类 是 一 个 枚 举 类 型 ， 如 代码 清单 34-12 所 示 。 


代码 清单 34-12 命令 配置 对 象 


public enum CommandEnum { 
ls("com.cbf41life.common.command.LSCommand"); 
private String value = ""，; 
// 定 义 构造 函数 ， 目 的 是 Data( ee ) 类 型 的 相 匹配 
private CommandEnum(String value)t{ 
this.value = value; 


} 

public String getValue(){ 
return this,.value; 

和 


// 返 回 所 有 的 enum 对 象 
public static List<String> getNames(){ 
commandEnum[] commandEnum = CommandEnum.values(); 
List<String> names = new ArrayList<String>(); 
for(CommandEnum c:commandEnum){ 
names.add(c.name( )); 
} 


return names,; 


为 什么 要 用 枚 举 类 型 ? 用 一 个 接口 来 管理 也 是 很 容易 实现 的 。 注 
意 CommandEnum 中 的 构造 画 数 CommandEnum(String value) 和 getValue 
类 ， 没 有 新 建 一 个 Enum 对 象 ， 但 是 可 以 直接 使 用 


CommandEnum.ls.getValue 方 法 获得 值 ， 这 葡 是 Enum 类 型 的 独特 地 方 。 
再 看 下 面 : 


ls("com.cbf41life.common.command.LSCommand"); 


征 不 是 很 特别 ? 是 的 ， 枚 举 的 基本 功能 就 是 定义 默认 可 选 值 ， 但 
征 Java 中 的 枚 举 功 能 又 增强 了 很 多 ， 可 以 添加 方法 和 属性 ， 基 本 上 束 是 
一 个 特殊 的 类 。 若 要 详细 了 解 Enum， 读 者 可 以 翻阅 一 下 相关 语法 书 。 


现在 剩 下 的 工作 就 是 写 一 个 Client 类 ， 然 后 看 看 运行 情况 如 何 ， 如 
代码 清单 34-13 所 示 。 


代码 清单 34-13 场景 > 


public class Client { 
public static void main(String[] args) throws IOException { 
Invoker invoker = new Invoker(); 
while(true)t{ 
//UNIX 下 的 默认 提示 符号 
System.out.print("#"); 
// 捕 获 输出 
String input = (new BufferedReader (new 
InputStreamReader (System.in))).readLine(); 
// 输 入 quit 或 exit 则 退出 
if(input.equals("quit") || 
input.equals("exit"))t{ 


return; 


System.out .println(invoker.exec(input ) ) ; 


Client 也 很 简单 ， 通 过 一 个 while 循 环 允许 使 用 者 持续 输入 ， 然 后 打 
印 出 返回 值 ， 运 行 结 末 如 下 : 


#]s 
filel 
file2 
file3 
file4 
#l]s -] 
drw-rw-rw root system 1024 2009-8-20 10:23 filel 
drw-rw-rw root system 1024 2009-8-20 10:23 file2 
drw-rw-rw root system 1024 2009-8-20 10:23 file3 


#l]s -a 


filel 
file2 
file3 


#quit 


我 们 已 经 实现 了 在 Windows 下 操作 UNIX 命 令 的 功能 ， 但 是 仅仅 一 
个 ls 命令 族 是 不 够 的 ， 我 们 要 扩展 ， 把 一 百 多 个 命令 都 扩展 出 来 ， 怎 么 
扩展 呢 ? 现在 增加 一 个 df 命令 族 ， 显 示 磁 副 的 大 小 ， 只 要 增加 类 图 就 
成 ， 如 图 34-5 所 示 。 


Tnvoker 


string csco(Sring_commandStr.) 
| 


ChassUiils 
+String execue(CommandVO vo) 
ee #Final List buildchain (Class abstractClass) 


ConumandVO LSCommand | DFCommand 
EE Rl | 
EE 


+final Strng handleMessage(CommandVO vo) 
+vold setNext(CommandName_operator) 
+String getOperateParam() 

+String echo(CommandVO vo) 


图 34-5 扩展 df 命令 后 的 类 图 


仅仅 增加 了 粗 框 的 部 分 ， 也 就 是 增加 DFCommand、AbstractDF 以 
及 实现 类 就 可 以 完成 扩展 功能 。 先 看 AbstractDF 代 码 ， 如 代码 清单 34- 


14 所 示 。 


代码 清单 34-14 df 命令 的 抽象 类 


public abstract class AbstractDF extends CommandName { 


// 默 认 人 参数 

public final static String DEFAULT_PARAM = "”"; 
// 参 数 k 

public final static String K_PARAM = "k"，; 

// 参 数 g 


public final static String G PARAM = "g"; 


与 前 面 一 样 的 功能 ， 定 义 选 项 名 称 。 接 下 来 是 三 个 实现 类 ， 都 非 


利 简 单 ， 如 代码 清单 34-15 所 示 。 


代码 清单 34-15 df 命令 的 具体 实现 类 


public class DF extends AbstractDF{ 
// 定 义 一 下 自己 能 处 理 什么 参数 
protected String getOperateparam() { 
return Super .DEFAULT_PARAM ， 


} 

// 命 令 处 理 

protected String echo(CommandVO vo) { 
return DiskManager .df(); 

} 


} 
public class DF_K extends AbstractDF{ 
// 定 义 一 下 自己 能 处 理 什么 参数 
protected String getOperateparam() { 
return super .K_PARAM 


} 
// 命 令 处 理 
protected String echo(CommandVO vo) { 
return DiskManager .df_k(); 
} 


} 
public class DF_G extends AbstractDF{ 
// 定 义 一 下 自己 能 处 理 什么 参数 
protected String getOperateparam() { 
return super.G_ PARANM; 


} 

// 命 令 处 理 

protected String echo(CommandVO vo) { 
return DiskManager .df_g(); 

} 


每 个 选项 的 实现 类 都 定义 了 自己 能 解析 什么 命令 ， 然 后 通过 echo 
方法 返回 执行 结果 。 在 三 个 实现 类 中 都 与 DiskManager 类 有 关联 关系 ， 
该 类 负责 与 操作 系统 有 关 的 功能 ， 是 必须 要 实现 的 ， 其 示例 代码 如 代 
码 清 单 34-16 所 示 。 


代码 清单 34-16 磁盘 管理 


public class DiskManager { 
// 上 默认 的 计算 大 小 
public static String df()t{ 
return 
"/\t10485760\Nn/usr\t104857600\n/home\t1048576000\n"，; 


} 
// 按 照 kb 来 计算 
public static String df_k()t{ 
return 
"/\t10240\n/usr\t102400\n/home\tt10240000\n"; 


} 
// 按 照 gb 计 算 
public static String df_g(){ 

return "/\t10\n/usr\t100\n/home\tt10000\n"; 
} 


以 上 为 示例 代码 ， 大 要 实际 计算 人 磁盘 大 小 ， 可 以 使 用 JNI 的 方式 或 
者 执行 操作 系统 的 命令 的 方式 获得 ， 特 别 是 JDK 1.6 提 供 了 获得 一 个 
root 目 录 大 小 的 方法 。 


然后 再 增加 一 个 DFCommand 命 令 ， 负 责 执行 命令 ， 如 代码 清单 34- 


17 所 示 。 


代码 清单 34-17 可 执行 的 df 命令 


public class DFCommand extends Command { 
public String execute(CommandVO vo) { 


return 


super.buildChain(AbstractDF.class).get(0).handleMessage(vo); 


3 
} 


最 后 一 步 


， 修 改 一 下 CommandEnum 配 置 ， 增 加 一 个 榴 举 项 ， 如 代 


码 清 单 34-18 所 示 。 


代码 清单 34-18 增加 后 的 枚 举 项 


public enum CommandEnum { 
ls("com.cbf41life.common.command.LSCommand"), 
df("com.cbf41life.common.command.DFCommand"); 
private String value = ""，; 
// 定 义 构造 画 数 ， 目 的 是 Data(value ) 类 型 的 相 匹 配 
private CommandEnum(String value)t{ 


this.value = value; 


public String getValue(){ 


} 
// 返 


return this.value; 


回 所 有 的 enum 对 象 


public static List<String> getNames(){ 


commandEnum[] commandEnum = CommandEnum.values(); 

List<String> names = new ArrayList<String>(); 

for(CommandEnum c:commandEnum){ 
names.add(c.name( )); 


} 
return Names, 
} 
} 
运行 结果 如 下 所 示 : 
#]s 
filel 


file2 


file3 

file4 

#df 

/ 10485760 
/usr 104857600 
/home 1048576000 
#df -k 

/ 10240 

/usr 102400 
/home t10240000 
#df -g 

/ 10 

/usr 100 

/home t10000 


# 


仅仅 增加 类 就 完成 了 变更 ， 这 才 是 我 们 要 的 结 末 :对 修改 关闭 ， 
对 扩展 开放 。 


34.2 混 编 小 结 


在 这 里 的 例子 中 用 到 了 以 下 模式 。 
e 责任 链 模式 


负责 对 命令 的 参数 进行 解析 ， 而 且 所 有 的 扩展 都 是 增加 链 数 量 和 
斑点 ， 不 涉及 原 有 的 代码 变更 。 


负责 命令 的 分 发 ， 把 适当 的 命令 分 发 到 指定 的 链 上 。 
e 模板 方法 模式 


在 Command 类 以 及 子 类 中 ，buildChain 方 法 是 模板 方法 ， 只 是 没 
有 基本 方法 而 已 ， 在 责任 链 模 式 的 CommandName 类 中 ， 用 了 一 个 典 
型 的 模板 方法 handlerMessage， 它 调用 了 基本 方法 ， 基 本 方法 由 各 个 实 
现 类 实现 ， 非 常 有 利于 扩展 。 


。 和 迭代 器 模式 


在 for 循 环 中 我 们 多 次 用 到 类 似 for(Class c:classes) 的 结构 ， 是 谁 来 
文 撑 该 方法 运行 ? 当然 是 迷 代 器 模 式 ， 只 是 JDK 已 经 把 它 融 入 到 了 API 


市 更 厂 便 使用 下 有 


可 能 读者 已 经 注意 到 了 ，"]s-l-a" 这 样 的 组 合 选 项 还 没有 处 理 。 确 
实 没 有 处 理 ， 以 下 提供 两 个 思路 来 处 理 。 


e 独立 处 理 


"ls-]-a" 等 同 于 "ls-la"， 也 等 同 于 "1s-al" 命 令 ， 可 以 把 "ls-la" 中 的 选 
项 "la" 作 为 一 个 参数 来 进行 处 理 ， 扩 展 一 个 类 就 可 以 了 。 该 方法 的 缺 
点 是 类 脱 胀 得 太 大 ， 但 是 简单 。 


e 混合 处 理 


修正 命令 族 处 理 链 ， 每 个 命令 处 理 节 点 运行 完毕 后 ， 继 续 由 后 续 
节点 处 理 ， 最 终 由 Command 类 组 装 结果 ， 根 据 每 个 节点 的 处 理 结果 ， 
组 合 后 生成 完整 的 返回 信息 ， 如 "ls-l-a" 就 应 该 是 LS 工 类 与 LS_A 类 两 
者 返回 值 组 装 的 结果 ， 当 然 链 上 的 节点 返回 值 就 要 放 在 Collection 类 型 
HT 


该 框架 还 有 一 个 名 称 ， 叫 做 命令 链 (Chain of Command) 模式 ， 
具体 来 说 就 是 命令 模式 作为 责任 链 模式 的 排头 兵 ， 由 命令 模式 分 发 具 
体 的 消息 到 责任 链 模 式 。 对 于 该 框 染 ， 读 者 可 以 继续 扩展 下 去 。 当 
然 ， 上面 的 程序 还 可 以 优化 ， 优 化 的 结 采 吏 是 Command 类 缩 为 一 个 


类 ， 通 过 CommandEnum 配 置 文件 类 传递 命令 ， 这 比较 容易 实现 ， 读 
者 可 以 上 自行 设计 。 


第 35 章 ”工厂 方法 模式 + 策略 模式 


35.1 迷你 版 的 交易 系统 


大 家 可 能 对 银行 的 交易 系统 充满 敬 旦 之 情 ， 一 听 说 是 银 行 的 IT 人 
员 ， 立 马 想 当然 地 认为 这 是 个 很 厉害 的 人 物 ， 那 我 们 今天 束 来 对 银行 
的 交易 系统 做 一 个 初步 探讨 。 国 内 一 家 大 型 集团 (全 球 500 强 之 一 ) 计 
划 建 立 全 国 “一 卡通 ”计划 ， 每 个 员工 配备 一 张 IC 卡 ， 该 卡 基本 上 就 是 
万 能 的 ,| 门禁 系 统 用 它 ， 办 公 系 统 用 它 ， 你 想 打 开 目 己 的 邮箱 ， 没 有 
它 束 外 想 了 ， 它 还 可 以 用 来 进行 消费 ， 比 如 到 食堂 吃饭 ， 到 园区 内 的 
商店 消费 ， 甚 至 洗 误 、 理 发 、 借 书 、 闫 书 等 都 可 以 用 它 ， 只 要 这 张 卡 
内 有 余额 ， 在 集团 内 部 就 是 一 张 借 记 卡 (当然 还 有 一 些 内 部 的 补助 通 
过 该 卡 发 放 ) 。 我 们 要 讲解 的 束 古 “一 卡通 ”项 目 联 机 交易 子 系统 ， 类 
似 于 银行 的 交易 系统 ， 可 以 说 它 是 交易 系统 的 mini 版 吧 。 


该 项 目 具有 一 定 的 挑战 性 ， 集 团 公司 的 架构 分 为 三 层 : 总 部 、 省 
级 分 部 、 市 级 机 构 ， 业 务 要 求 是 “一 卡通 ”推广 到 全 国 ， 一 名 员工 从 北 
京 出 差 到 了 上 海 ， 赁 一 卡通 能 在 北京 做 的 事情 在 上 海 同样 能 完成 。 对 
于 联机 交易 子 项 目 ， 异 地 分 支 机 构 与 总 部 之 间 的 通信 采用 了 MQ 
(Message Queue， 消 息 队 列 ) 传递 消息 ， 也 就 是 我 们 观察 者 模式 的 
BOSS 版 ， 与 目前 的 通过 POS 机 刷 信 用 卡 基 本 上 是 一 个 道理 。 


联机 交易 子 系统 有 一 个 非常 重要 的 子 模块 (Module) 扣 款 子 
模块 。 这 个 模块 太 重要 了 ! 从 业务 上 来 说 ， 扣 球 失 败 束 代表 看 所 有 的 
商业 交易 关闭 ， 这 是 不 允许 发 生 的 ;， 从 技术 上 来 说 ， 扣 款 的 异常 处 
理 、 事 务 处 理 、 鲁 棱 性 都 是 不 容 色 视 的 ， 特 别 是 饭 点 时 间 ， 并 发 量 是 
很 罗 怖 的 ， 这 对 架构 师 提 出 了 很 高 的 要 求 。 


我 们 详细 分 析 一 下 扣 歌 子 模 块 ， 每 个 员工 都 有 一 张 IC 卡 ， 他 的 IC 
卡 上 有 以 下 两 种 金额 。 


固定 金额 是 指 员 工 不 能 提现 的 金额 ， 这 部 分 金额 只 能 用 来 特定 消 
员工 日 党 


常 必需 的 消费 ， 例 如 食堂 内 吃饭 、 理 发 、 健 身 等 活动 。 


目 由 金额 是 可 以 提现 的 ， 当 然 也 可 以 用 于 消费 。 每 个 月 初 ， 总 部 
都 会 为 每 个 员工 的 IC 卡 中 打 入 固定 数量 的 金额 ， 然 后 提倡 大 家 在 集团 
内 的 商店 消费 。 


在 实际 的 系统 开发 中 ， 织 构 设 计 采 用 的 是 一 张 IC 卡 绑 定 两 个 账 
户 : 国定 账 己 和 目 由 账 豆 ， 本 书 为 了 人 商 化 摘 述 ， 还 是 使 用 固定 金额 和 
自由 金额 的 概念 。 有 既然 有 消费 ， 系 统 肯 定 有 扣 款 处 理 ， 系 统 内 有 两 套 
扣 款 规则 。 


e 扣 球 策略 一 


该 类 型 的 扣 球 会 对 IC 卡 上 的 两 个 金额 产生 影响 ,计算 公式 如 下 : 


IC 卡 固定 余额 =IC 卡 现 有 固定 余额 -交易 金额 /2 


IC 卡 目 由 余额 =IC 卡 现 有 目 由 金额 -交易 金额 /2 


也 融 是 说 ， 该 类 型 的 消费 分 别 在 固定 金额 和 目 由 金 铬 上 各 扣除 一 
半 。 它 适用 于 固定 消费 场景 例如 吃饭 、 理 发 等 情况 下 的 扣 款 ， 这 么 做 
是 为 了 防止 乱 请 客 ， 你 请 别人 吃饭 时 目 己 也 要 出 一 半 。 


e 扣 球 策略 二 


全 部 从 目 由 金额 上 扣除 ， 由 于 集团 内 的 各 种 消费 、 服 务 非常 齐 
全 ， 而 且 比 市 面 价格 稍 低 ， 员 工 还 是 很 乐意 到 这 里 消费 的 ， 而 且 很 多 
员工 本 号 吏 住 在 集团 附近 ， 基 本 上 融 是 “公司 即 家 ， 家 即 公司 ”。 


今天 要 讲 的 重点 距 是 这 两 种 消费 的 扣 球 策略 该 上 怎样 设计 ? 要 知道 
这 种 联机 交易 ， 日 后 允许 大 规模 变更 的 可 能 性 基本 上 起 零 ， 所 以 系统 
设计 的 时 候 要 做 到 可 拆卸 (Pluggable) ， 避 人 免 日 后 维护 的 大 量 开 支 。 


很 明显 ， 这 是 一 个 策略 模式 的 实际 应 用 ， 但 是 你 还 记得 策略 模式 
征 有 缺陷 的 吗 ? 它 的 具体 策略 必须 其 露出 去 ， 而 且 还 要 由 上 层 模 块 初 
化 ， 这 不 合适 ， 与 迪 米 特 法 则 有 冲突 ， 高 层次 模块 对 低层 次 的 模块 


应 该 仅仅 处 在 “接触 ?的 层次 上 ， 而 不 应 该 是 “ 硒 合 ”的 关系 ， 否 则 ， 维 护 
的 工作 量 束 会 非 第 大 。 问 题 提 出 了 ， 那 我 们 就 应 该 想 办 法 来 修改 这 个 
缺陷 ， 正 好 工厂 方法 模式 可 以 帮 我 们 产生 指定 的 对 象 ， 但 是 问题 又 来 
了 ， 工 厂 方法 模式 要 指定 一 个 类 ， 它 才能 产生 对 象 ， 怎 么 办 ? 引入 一 
个 配置 文件 进行 映射 ， 避 免 系 统 僵化 情况 的 发 生 ， 我 们 以 枚 举 类 完成 


该 任务 。 


还 有 一 个 问题 ， 一 个 交易 的 扣 吉 模 式 下 固定 的 ， 根 据 其 交易 编号 
而 定 ， 那 我 们 怎样 把 区 易 编 号 与 扣 款 策略 对 应 起 来 呢 ? 采用 状态 模式 
或 责任 链 模式 都 可 以 ， 如 采 采 用 状态 则 认为 交易 编号 束 是 一 个 交易 对 
象 的 状态 ， 对 于 一 笔 确定 的 交易 〈 一 个 已 经 生成 了 的 对 象 ) ， 它 的 状 
态 不 会 从 一 个 状态 过 小 到 另 一 个 状态 ， 也 吏 是 说 它 的 状态 只 有 一 个 ， 
执行 完毕 后 即 结束 ， 不 存在 多 状态 的 问题 ; 如 有 果 采 用 责任 链 模 式 ， 则 
可 以 用 交易 编码 作为 链 中 的 判断 依据 ， 由 每 个 执行 节点 进行 判断 ， 返 
回 相 应 的 扣 球 模式 。 但 十 在 实际 中 ， 采 用 了 关系 型 数据 库存 储 扣 球 规 
则 与 交易 编码 的 对 应 关系 ， 为 了 简化 该 部 分 的 讲义 ， 我 们 在 下 面 的 设 
计 中 使 用 了 条 件 判断 语句 来 代 符 。 


还 有 ， 这 人 么 复杂 的 扣 亚 模块 总 要 进行 一 个 封装 吧 ， 不 能 让 上 层 的 
业务 模块 直接 深入 到 模块 的 内 部 ， 于 是 门面 模式 又 摆 在 了 眼前 。 


分 析 完 童 ， 我 们 要 先 画 出 类 网 ， 做 设计 要 遵循 这 样 一 个 原则 : 先 
选 最 简单 的 业务 ， 然 后 画 出 类 图 。 那 我 们 先 定义 交易 中 用 到 的 两 个 


类 : IC 卡 类 和 交易 类 ， 如 图 35-1 所 示 。 


-Strng cardNo() 


-String trade No 
-Int steadyMoney() -Int amount 


-int freeMoney() 


+getter/setter amount() 
+getter/setter trade No() 


+getter/settr cardNo0) 
+getter/settr steadyMoney!() 
+getter/settr freeMoney() 


交易 信息 : 


sz 四 - 和 
IC 卡 信息 : stradeNO 交易 编码 


steadyMoney 固定 金额 


amount 交易 金富 


freeMoney 目 由 金额 
图 35-11C 卡 类 和 交易 类 


每 个 IC 卡 有 三 个 属性 ， 分 别 是 IC 卡号 码 、 固 定金 额 、 自 由 金额 ， 
然后 通过 gettersetter 方 法 来 访问 ， 如 代码 清单 35-1 所 示 。 


代码 清单 35-1 IC 卡 类 


public class Card { 
//IC 卡 号 码 
private String cardNo=""; 
// 卡 内 的 固定 交易 金额 
private int steadyMoney =0; 
// 卡 内 自由 交易 金额 
private int freeMoney =0; 
//getter/setter 方 法 
public String getCardNo() { 

return cardNo; 


} 
public void setCardNo(String cardNo) { 


this.cardNo = cardNo; 


public int getSteadyMoney() { 
return steadyMoney; 


public void setSteadyMoney(int steadyMoney) { 
this.steadyMoney = SteadyMoney ; 


} 
public int getFreeMoney() { 
return freeMoney; 


public void setFreeMoney(int freeMoney) { 
this.freeMoney = freeMoney; 
} 


细心 的 读者 可 能 注意 到 ， 人 金额 怎么 都 是 整数 类 型 呀 ， 应 该 是 double 
类 型 或 者 BigDecimal 类 型 呀 。 是 ， 一 般 非 银行 的 交易 系统 ， 比 如 超市 的 
收银 系统 ， 系 统 内 部 是 存放 的 int 类 型 ， 在 显示 的 时 候 才 转换 为 货币 类 


型 。 


交易 信息 Trade 类 ， 负 责 记 录 每 一 笔 灾 易 ， 它 是 由 监听 程序 监听 
MQ 队 列 而 产生 的 ， 有 两 个 属性 : 交易 编号 和 交易 金额 ， 其 中 的 交易 编 
号 对 整个 交易 非常 重要 ，18 位 字符 〈 在 银行 的 交易 系统 中 ， 这 里 可 不 
是 字符 串 ， 一 般 是 十 进 制 数字 或 二 进 制 数字 ， 要 考虑 系统 的 性 能 ， 数 
字 运 算 可 比 字 符 运算 快 得 多 ) ， 包 括 POS 机 编号 、 商 户 编号 、 校 验 码 
等 ， 我 们 这 里 暂时 用 不 到 ， 束 不 多 做 介绍 ， 我 们 只 要 知道 它 十 一 个 非 
党 有 用 的 编码 束 成 。 交 易 金 额 为 整数 类 型 ， 实 际 金额 放大 100 售 即 可 。 
如 代码 清单 35-2 所 示 。 


代码 清单 35-2 交易 类 


public class Trade { 
// 交 易 编号 


private String tradeNo = ""; 
// 交 易 金 额 

private int amount = 0; 
//getter/setter 方 法 


public String getTradeNo() { 
return tradeNo; 


public void setTradeNo(String postNo) { 
this.tradeNo = postNo; 


} 
public int getAmount() { 
return amount; 


public void setAmount(int amount) { 
this.amount = amount ， 
} 


两 个 最 简单 也 是 在 应 用 中 最 常 使 用 的 对 象 定 义 完毕 ， 下 面 束 需 
来 定义 荣 上 略 了 ， 非 第 明显 的 策略 模式 ， 类 图 如 图 35-2 所 示 。 


典型 的 策略 模式 ， 扣 款 有 两 种 策略 : 固定 扣 款 和 自由 扣 款 。 下 面 
我 们 来 看 代码 ， 移 看 抽象 策略 ， 也 束 是 扣 款 接口 ， 如 代码 清单 35-3 所 


修 ° 


代码 清单 35-3 扣 款 策略 接口 


public interface IDeduction { 
// 扣 款 ， 提 供 交 易 和 卡 信息 ， 进 行 扣 款 ， 并 返回 扣 款 是 否 成 功 
public boolean exec(Card card,Trade trade); 


回 定 扣 款 的 规则 是 固定 金额 和 目 由 金额 各 扣除 交易 金额 的 一 半 ， 
如 代码 清单 35-4 所 示 。 


代码 清单 35-4 扣 款 策略 一 


public class SteadyDeduction implements IDeduction { 


// 固 定性 交易 扣 款 


public boolean exec(Card card，Trade trade) { 


// 固 定金 额 和 


自由 金额 各 扣除 50% 


int halfMoney = (int)Math.rint(trade.getAmount() / 


2.0); 


card.setFreeMoney(card.getFreeMoney() - halfMoney); 
card.setSteadyMoney(card.getSteadyMoney() - 


halfMoney ) ; 


return true; 


DeductionContext 
[和 


| +DeductionContext(IDeduction deduction) 
+boolean exec(Card card, Trade trade) 


<<mterface>> 
IDeduction 


+boolean exec(Card card, Trade trade) 


让 


FreeDe sti 


目 和 


图 35-2 扣 款 策略 类 图 


这 个 具体 菏 上 略 也 非常 简单 ， 束 古 两 个 金额 各 目 减 去 交易 额 的 一 半 
(注意 除数 是 2.0， 可 不 是 2) ， 然 后 再 四 舍 五 入 ， 算 法 确实 简单 。 该 逻 
辑 没 有 考虑 账户 余额 不 足 的 情况 ， 也 没有 考虑 异 向 情况 ， 比 如 并 发 情 


况 ， 读 者 可 以 想 想 看 ， 一 张 卡 有 两 笔 消费 同时 发 生 时 ， 和 是 不 是 束 发 生 


错误 了 ? 一 张 卡 同时 有 两 笔 消 费 会 出 现 这 种 情况 吗 ? 会 的 ， 网 络 阻塞 
的 情况 ，MQ 多 通道 发 送 ， 在 网 络 粽 忙 的 情况 下 是 有 可 能 出 现 该 问题 ， 
这 里 束 不 多 介绍 ， 有 兴趣 的 读 首 可 以 看 看 MQ 的 资料 。 我 们 在 这 里 的 讲 
解 实 现 的 是 一 个 快乐 路 径 ， 认 为 所 有 的 交易 都 是 在 安全 可 靠 的 环境 中 
发 生 的 ， 并 且 所 有 的 系统 环境 都 满足 我 们 的 要 求 。 我 们 再 来 看 另 一 个 
策略 ， 这 个 策略 更 简单， 如 代码 清早 35-5 所 示 。 


代码 清单 35-5 扣 款 策略 二 


public class FreeDeduction implements IDeduction { 
// 自 由 扣 款 
public boolean exec(Card card, Trade trade) { 
// 直 接 从 自由 余额 中 扣除 
card.setFreeMoney(card.getFreeMoney() - 
trade,getAmount() ) ; 
return true; 
} 


上 


卡 内 的 目 由 金额 减 去 交易 金额 再 修改 卡 内 目 由 金额 束 完 事 了 ， 异 
常情 况 不 考虑 。 这 两 个 具体 的 策略 与 我 们 的 交易 类 型 没有 任何 关系 ， 
也 不 应 该 有 关系 ， 宽 上 略 模式 束 古 提供 两 个 可 以 相互 车 换 的 全 略 ， 至 于 
在 什么 时 候 使 用 什么 策略 ， 则 不 十 由 筑 略 模式 来 决定 的 。 策 略 模 式 还 
有 一 个 角色 没 出 场 ， 即 封 外 角色 ， 如 代码 清单 35-6 所 示 。 


代码 清单 35-6 扣 球 策略 的 封 婆 


public class DeductionContext { 
// 扣 款 策 B 
private IDeduction deduction = null; 
// 构 造 函 数 传递 策 B 


public DeductionContext(IDeduction _deduction)t{ 
this.deduction = _deduction; 


} 

// 执 行 扣 款 

public boolean exec(Card card, Trade trade)t{ 
return this.deduction.exec(card, trade); 

} 


一 


典型 的 策略 上 下 文 角 色 。 扣 款 模块 的 策略 已 经 定义 完毕 了 ， 然 后 
需要 想 办 法 解决 策略 模式 的 缺陷 ， 它 把 所 有 的 策略 类 都 暴露 出 去 ， 上 暴 
露 得 越 多 以 后 的 修改 风险 也 就 越 大 。 怎 么 修改 呢 ? 增加 一 个 映射 配置 
文件 ， 实 现 策 略 类 的 隐藏 。 我 们 使 用 枚 举 担当 此 任 ， 对 策略 类 进行 映 
射 处 理 ， 避 免 高 层 模块 直接 访问 策略 类 ， 同 时 由 工矿 方 法 模式 根据 映 
射 产生 策略 对 象 ， 类 图 如 图 35-3 所 示 。 
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策略 工厂 


StrategyFactory 
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策略 的 管理 类 


图 35-3 策略 工厂 类 图 


又 是 一 个 简单 得 不 能 再 位 和 单 的 模式 一 一 工厂 方法 模式 ， 通 过 
StrategyMan 仙 贡 对 具体 策略 的 映射 ， 如 代码 清单 35-7 所 示 。 


代码 清单 35-7 策略 枚 举 


public enum StrategyMan { 
SteadyDeduction("com.cbf41life.common.SteadyDeduction"), 
FreeDeduction("com.cbf41life.common.FreeDeduction"); 
String value = ""， 
private strategyMan(String _Value){ 
this.value = _value; 


} 

public String getValue( ){ 
return this.value; 

} 


类 似 的 代码 解释 过 很 多 裔 了 ， 不 再 多 说 ， 它 就 是 一 个 登记 容 絮 ， 
所 有 的 具体 策略 都 在 这 里 登记 ， 然 后 提供 给 工厂 方法 模式 。 策 略 工 厂 
如 代码 清单 35-8 所 示 。 


代码 清单 35-8 策略 工厂 


public class StrategyFactory { 
// 策 略 工 厂 
public static IDeduction getDeduction(StrategyMan strategy) 


IDeduction deduction = null; 
try { 
deduction = 
(IDeduction)Class.forName(strategy.getValue()).newInstance( ); 
} catch (Exception e) { 
异常 处 理 


return deduction; 


一 个 简单 的 工 三， 根据 策略 管理 类 的 枚 举 项 创建 一 个 策略 对 和 象 ， 
简单 而 实用 ， 策 略 模式 的 缺陷 也 弥补 成 功 。 那 这 么 复杂 的 系统 怎么 让 
高 层 模块 访问 ? (你 看 不 出 复杂 ? 那 是 因为 我 们 写 的 都 是 快乐 路 径 ， 
太 多 情况 都 没有 考虑 ， 在 实际 项 目 中 仅 吏 并 发 处 理 和 事务 管理 这 两 部 
分 就 够 你 头疼 了 。) 既然 系统 很 复杂 ， 是 不 是 需要 封装 一 下 。 我 们 请 
出 门面 模式 进行 封闭 ， 如 代码 清单 35-9 所 示 。 


代码 清单 35-9 扣 款 模 块 封装 


public class DeductionFacade { 
// 对 外 公布 的 扣 款 信息 
public static Card deduct(Card card,Trade trade)t{ 
// 获 得 消费 策 B 
StrategyMan reg = getDeductionType(trade); 
// 初 始 化 一 个 消费 策略 对 象 
IDeduction deduction = 
StrategyFactory .getDeduction(reg ) ; 
// 产 生 一 个 策略 上 下 文 
DeductionContext context = new 
DeductionContext (deduction); 
// 进 行 扣 款 处 理 
context .exec(card，trade ) 
// 返 回扣 款 处 理 完毕 后 的 数据 
return card; 


} 
// 获 得 对 应 的 商户 消费 策 B 
private static StrategyMan getDeductionType(Trade trade)t{ 
// 模 拟 操作 
if(trade.getTradeNo().contains("abc"))t{ 
return StrategyMan.FreeDeduction,; 


}elsef 


return StrategyMan.SteadyDeduction; 


这 次 为 什么 要 先 展示 代码 而 后 写 类 图 呢 ? 那 古 因为 这 段 代码 比 写 
类 图 更 能 让 你 理解 。 读 者 注意 一 下 getDeductionType 方 法 ， 这 个 方法 在 
实际 项 目 中 是 存在 的 ， 但 是 与 上 面 的 写法 有 天 培 之 别 ， 因 为 在 实际 项 
目 中 ， 数 据 库 中 保存 了 策略 代码 与 交易 编码 的 对 应 关系 ， 直 接 通过 数 
据 库 的 SQL 语句 就 可 以 返回 对 应 的 扣 款 策略 。 这 里 我 们 采用 大 家 最 熟 
悉 的 条 件 转移 来 实现 ， 也 是 比较 清晰 和 容易 理解 的 。 


可 能 读者 要 问 了 ， 在 门面 模式 中 已 经 明确 地 说 明 ， 门 面 类 中 不 允 
许 有 业务 逻辑 存在 ,但 十 你 这 里 还 是 有 了 一 个 getDeductionType 方 法 ， 
它 可 代表 的 古 一 个 判断 逻辑 蚜 ， 这 是 为 什么 呢 ? 古 的 ， 该 方法 完全 可 
以 移 到 其 他 Hepler 类 中 ， 由 于 我 们 是 示例 代码 ， 暂 没有 明确 的 业务 侣 
义 ， 故 编写 在 此 处 ， 读 着 在 实际 应 用 中 ， 请 把 该 方法 放置 到 其 他 类 
i 


好 ， 所 有 用 到 的 模式 都 介绍 完毕 了 ， 我 们 把 完整 的 类 图 整理 一 
下 ， 如 图 35-4 所 示 。 
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图 35-4 扣 球 子 模 块 完整 类 图 


真实 系统 比 这 复杂 得 多 ， 有 了 我 们 之 前 的 分 析 ， 这 个 图 还 古 比 较 
容易 看 懂 的 。 我 们 所 有 的 开发 都 完成 了 ， 是 不 是 应 该 写 一 个 测试 类 来 
展示 一 下 我 们 的 成 果 ， 如 代码 清单 35-10 所 示 。 


代码 清单 35-10 场景 


public class Client { 
// 模 拟 交 易 


public static void main(String[] args) { 


成 功 ! "); 


// 初 始 化 一 张 IC 卡 
Card card = initIC(); 
// 显 示 一 下 卡 内 信息 


System,out,.println("======== 初 始 卡 信息 : 


ShowCard(card ) ; 
// 是 否 停止 运行 标志 
boolean flag = true; 
while(flag)t{ 
Trade trade = createTrade( ); 


DeductionFacade.deduct(card, trade); 
// 交 易 成 功 ， 打 印 出 成 功 处 理 消息 
System.out.println("NXn====== 交 易 任 证 


System,out ,println(trade,getTradeNo()+" 交易 


System,out,.println(" 本 次 发 生 的 交易 金额 为 : "+ 
trade.getAmount()/100.0+" 元 "); 


// 展 示 一 下 卡 内 信息 
showCard(card); 
System.out .print("NXn 是 否 需 要 退 


出 ? (Y/N)"); 


if(getInput().equalsIgnoreCase("y"))t{ 


flag = false;  // 退 出 
} 
} 


} 
// 初 始 化 一 个 IC 卡 
private static Card initIC(){ 


} 


Card card = new Card(); 
card.setCcardNo("1100010001000" ) ; 
card.setFreeMoney(100000); //1000 元 
card.setSteadyMoney(80000); //800 元 
return card; 


// 产 生 一 条 交易 
private static Trade createTrade(){ 


} 
A/ 打印 


Trade trade = new Trade( ); 
System.out .print(" 请 输入 交易 编号 : ")， 
trade. setTradeNo(getInput()); 
System.out.print("i 请 输入 交易 金额 ys 


trade.setAmount(Integer.parseInt(getInput())); 


// 返 回 交易 
return trade; 


当前 卡 内 交易 余额 


public static void showCard(Card card){ 
System.out.println("IC 卡 编号 :" + card.getCardNo()); 
System.out .println(" 固 定 类 型 余额 ; "+ 
card.getsteadyMoney()/100.0 + " 元 "); 
System.out.println(" 自 由 类 型 余额 ;， "+ 
card.getFreeMoney()/100.0 + " 元 "); 


} 

// 获 得 键 副 输入 

public static String getInput(){ 
String str ="",; 
try { 


str=(new BufferedReader (new 
InputStreamReader(System.in))).readLine(); 
} catch (IOException e) { 


// 异 常 处 理 
return str; 
} 
} 
类 比较 长 ， 耐 心 看 还 是 非常 们 单 的 ， 对 其 中 Client 类 的 方法 说 明 如 
下 : 


e initIC 方 法 

初始 化 一 张 IC 卡 ， 方 便 进 行 测试 。 
e createTrade 方 法 

创建 一 笔 交 易 ， 完 成 测试 任务 。 

e showCard 方 法 
显示 IC 卡 内 的 信息 。 


e getInput 方 法 


获得 从 键盘 输入 的 字符 ， 以 回 车 符 作为 终结 标志 。 


方法 介绍 完毕 了 ， 我 们 运行 一 下 看 看 ， 结 采 如 下 所 未: 


A 初始 上 E 信 /EN 


IC 卡 编号 :1100010001000 


固定 类 型 余额 : 800.0 元 


abcdef 交易 成 功 ! 


本 次 发 生 的 交易 金额 为 : 100.0 元 


IC 卡 编号 :1100010001000 


国定 类 型 余额 : 800.0 元 


自由 类 型 余额 : 900.0 元 


是 否 需 要 退出 ? (YN) 


我 们 模拟 了 一 笔 目 由 消费 ， 直 接 从 目 由 类 型 金额 中 扣除 了 。 我 们 
再 模拟 一 笔 固 定 类 型 的 消费 ， 运 行 结 末 如 下 所 示 : 


0 初始 上 E 信 /EN 


IC 卡 编号 :1100010001000 


国定 类 型 余额 : 800.0 元 


自由 类 型 余额 : 1000.0 元 


abcdef 交易 成 功 ! 


本 次 发 生 的 交易 金额 为 : 100.0 元 


IC 卡 编号 :1100010001000 


1001 交易 成 功 ! 


本 次 发 生 的 交易 金额 为 : 12.34 元 


IC 卡 编号 :1100010001000 


国定 类 型 余额 : 793.83 元 


自由 类 型 余额 : 893.83 元 


是 否 需 要 退出 ? (YN) 


交易 成 功 ! 到 这 里 为 止 ， 联 机 交易 中 的 扣 款 子 模块 开发 完毕 了 
征 不 旦 很 简单 ， 银 行业 的 交易 系统 也 区 是 这 么 回 事 ! 


35.2 混 编 小 结 


回顾 一 下 我 们 在 该 案例 中 使 用 了 几 个 模式 。 
e 策略 模式 、 


负责 对 扣 款 策略 进行 封闭， 保证 两 个 策略 可 以 目 由 切换 ， 而 且 日 
后 增加 扣 蒜 策略 也 非常 简单 容易 。 


e 工厂 方法 模式 


修正 策略 模式 必须 对 外 烘 露 具体 策略 的 问题 ， 由 工厂 方法 模式 直 
接 产 生 一 个 具体 策略 对 象 ， 而 其 他 模块 则 不 需要 依赖 具体 的 策略 。 


e 1] 面 模式 


人 负责 对 复 洒 的 扣 球 系统 进行 封 狠 ， 封 闭 的 结果 就 是 避免 高 层 模 块 
深入 子 系 统 内 部 ， 同 时 提供 系统 的 高 内 聚 、 低 厢 合 的 特性 。 


我 们 主要 使 用 了 这 三 个 模式 ， 它 们 的 好 处 是 灵活 、 稳 定 ， 我 们 可 
以 设想 一 下 可 能 有 哪些 业务 变化 。 


e 扣 款 策略 变更 


增加 一 个 新 扣 球 策略 ， 三 步 束 可 以 完成 :实现 IDeduction 接 口 ， 增 
加 StrategyMan 配 置 项 ， 扩 展 扣 球 策略 的 利用 (也 就 是 门面 模式 的 
getDeductionType 方 法 ， 在 实际 项 目 中 这 里 只 需要 增加 数据 库 的 配置 
项 ) 。 城 少 一 个 策略 很 简单 ， 修 改 扣 款 策略 的 利用 即 可 。 变 更 一 个 扣 
秩 策 略 也 很 商 单 ， 扩展 一 个 实现 类 口 承 可 以 了 。 


e 变更 扣 款 策略 的 利用 规则 


我 们 的 系统 不 想 大 修改 ， 还 记得 我 们 提出 的 状态 模式 吗 ? 这 个 束 
古 为 策略 的 利用 服务 的 ， 变 更 它 束 能 满足 要 求 。 想 把 IC 卡 也 纳入 策略 
利用 的 规则 也 不 复杂 。 其实 这 个 变更 还 真 发 生 了 ， 系 统 投 产后 ， 业 务 
提出 考虑 退休 人 员 的 情况 ， 退 休 人 员 的 IC 卡 与 普通 在 职员 工 一 样 ， 但 
征 它 的 扣 蒜 不 仅仅 是 根据 交易 编码 ， 还 要 根据 IC 卡 对 象 ， 系 统 的 变更 
做 法 是 增加 一 个 扣 款 策略 ， 同 时 扩展 扣 款 利用 党 略 ， 也 殉 是 数据 库 的 
配置 项 ， 在 getDeductionType 中 新 扩展 了 一 个 功能 : 根据 IC 卡号 ， 确 认 
征 否 是 退 体 人员， 是 退休 人 员 ， 则 使 用 新 的 扣 款 策略 ， 这 是 一 个 非常 
简单 的 扩展 。 


这 就 是 一 个 mini 版 的 金融 交易 系统 ， 没 蛤 复杂 的 ， 剩 下 的 问题 就 
征 开 始 考虑 系统 的 鲁 棒 性 ， 这 才 是 难点 。 


第 36 章 ”观察 着 模式 + 中 介 痢 模式 


36.1 事件 触发 右 的 开发 


大 家 都 应 该 做 过 曙 面 程序 的 开发 吧 ， 比 如 编写 一 个 EXE 文 件 ， 或 
者 使 用 Java Swing 编写 一 个 应 用 程序 ， 或 者 是 用 Delphi、C 编 写 C/S 结 构 
的 应 用 系统 ， 即 使 这 些 都 没有 做 过 ， 那 也 总 编写 过 B/S 结 构 的 页 面 吧 ? 
回忆 一 下 开发 过 程 ， 大 家 是 不 是 经 常 使 用 文本 框 和 按钮 这 两 个 控件 ? 
比如 设计 一 个 按钮 ， 那 总 要 编写 鼠标 点 击 处 理 ， 你 是 不 是 这 样 开发 : 
在 按钮 的 onClick 函 数 中 编写 自己 的 逻辑 代码 ， 然 后 鼠标 点 击 测试 ， 该 
代码 就 会 运行 。 大 家 有 没有 想 过 为 什么 我 们 点 击 了 按钮 就 会 触发 我 们 
自己 编写 的 代码 呢 ? 浏览 器 怎么 知道 操作 者 按 了 按钮 要 触发 该 事件 
呢 ? 鼠标 点 击 动作 、 按 钮 、 上 自己 编写 的 代码 之 间 是 如 何 关联 起 来 呢 ? 


我 们 今天 的 任务 吏 是 来 模拟 类 似 触发 过 程 。 我 们 这 样 分 析 : 有 一 
个 产品 (不管 是 Frame 还 是 Button 或 者 是 Radio) ， 它 有 多 个 触发 事件 ， 
它 产 生 的 时 候 触发 一 个 创建 事件 ， 修 改 的 时 候 触发 修改 事件 ， 删 除 的 
时 候 触 发 删除 事件 ， 这 就 类 似 于 我 们 的 文本 框 ， 初 始 化 (也 就 是 创 
建 ) 的 时 候 要 触发 一 个 onLoad 或 onCreate 事 件 ， 修 改 的 时 候 触发 
onChange 事 件 ， 双 击 (类 似 于 删除 ) 的 时 候 又 触发 onDbClick 事 件 ， 我 们 
今天 的 目标 区 是 来 思考 怎么 实现 这 样 一 个 架构 。 


设计 都 是 先 易 后 难 ， 我 们 先 从 最 简单 的 部 分 入 手 。 首 先 需 要 一 个 
产品 ， 并 且 该 产品 要 有 创建 、 修 改 、 销 毁 的 动作 ， 很 明显 这 就 是 一 个 
工厂 方法 模式 。 同 时 产品 也 可 以 通过 克隆 方式 产生 ， 这 与 我 们 在 GUI 设 
计 中 经 党 使 用 的 复制 烙 贴 操作 相 类 似 ， 要 不 界面 上 那么 多 的 文本 框 ， 
不 使 用 复制 粳 贴 ， 不 素 死 人 才 怪 呢 ， 那 这 非 肖 明 显 就 古 原型 模式 。 
好 ， 分 析 到 这 里 ， 我 们 先 把 这 部 分 的 类 图 建立 起 来 ， 如 图 36-1 所 示 。 


很 熟悉 的 类 图 ， 与 工厂 方法 模式 的 通用 类 图 非常 相似 ， 但 不 完 
。 有 什么 差别 呢 ? 注意 看 产品 类 的 私有 属性 canChanged 和 构造 画 
， 它 们 有 特殊 的 用 途 。 在 该 类 图 中 ， 我 们 使 用 了 工厂 方法 模式 创建 
产品 ， 使 用 原型 模式 让 对 象 可 以 被 拷贝 ， 仅 仅 这 两 个 模式 还 不 足以 解 
决 我 们 的 问题 ， 想 想 看 ， 产 品 的 产生 是 有 一 定 的 条 件 的 ， 不 是 谁 想 产 
生 就 产生 ， 否 则 怎么 能 够 触发 创建 事件 呢 ? 因此 需要 限定 产品 的 创建 
者 ， 所 以 我 们 在 类 图 中 把 产品 和 工厂 的 关系 定位 为 组 合 关系 ， 而 不 是 
简单 的 聚集 或 依赖 关系 。 换 句 话说 ， 产 品 只 能 由 工厂 类 创建 ， 而 不 能 
被 其 他 对 象 通过 new 方 式 创建 ， 因 此 我 们 在 这 里 还 用 到 一 个 单 来 源 调 用 
(Single Call) 方法 解决 该 问题 。 这 是 一 个 方法 ， 不 是 一 个 设计 模式 ， 
我 马上 给 大 家 讲解 它 和 如何 工 作 的 。 


全 


ou 


料 
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+Product createProduct(String name) -boolean canChanged = false 
+void abandonProduct(Product p) HProduct(ProductManager manager, Strng name) 


+void editProduct(Product p, String name) HString getNameO) 
+void setName(String name) 


+boolean isCreateaProduct() 
+Product clone(Product p) +Product clone() 


图 36-1 产品 创建 工厂 
我 们 先 来 看 产品 类 的 源 代码 ， 它 比较 简单 ， 如 代码 清单 36-1 所 示 。 


代码 清单 36-1 产品 类 


public class Product implements Cloneabletf 
// 产 品名 称 
private String name; 
// 是 否 可 以 属性 变更 
private boolean canChanged = false; 
// 产 生 一 个 新 的 产品 
public Product(ProductManager manager,String _name)t{ 
// 人 允许 建立 产品 
Ifl(manager .IsCreateProduct( ) ){ 
canChanged =true 
this.name = _name; 


S 
public String getName() { 
return name; 


public void setName(String name) { 
if(canChanged)t{ 
this.name = name; 
} 


} 
// 禾 写 clone 方 法 
Q@Override 


public Product clone(){ 
Product p =null; 


try { 
p =(Product)super.clone(); 

} catch (CloneNotSupportedException e) { 
e.printStackTrace( ); 

} 


return p; 


在 产品 类 中 ， 我 们 只 定义 产品 的 一 个 属性 ， 产品 名 称 (name) ， 
并 实现 了 getter/setter 方 法 ， 然 后 我 们 实现 了 它 的 dlone 方 法 ， 人 确保 对 象 是 
可 以 被 拷贝 的 。 还 有 一 个 特殊 的 地 方 是 我 们 的 构造 画 数 ， 它 怎么 
求 传递 进来 一 个 工厂 对 象 ProductManager 呢 ? 保留 你 的 好 奇 心 ， 马 上 为 
你 揭 瞬 答案 。 我 们 继续 看 代码 ， 工 厂 类 如 代码 清单 36-2 所 示 。 


代码 清单 36-2 工厂 类 


pe | rou Manayer { 
否 可 以 创建 一 个 产品 
es boolean isPermittedCreate = false; 
// 建 立 一 个 产品 
public Product createProduct(String name)t{ 
// 首 先 修改 权限 ， 人 允许 创建 
isPermittedCreate = true; 
Product p = new Product(this,nanme); 
return p; 


由 


} 

// 废 弃 一 个 产品 

public void abandonProduct(Product p)t{ 
// 销 毁 一 个 产品 ， 例 如 删除 数据 库 记 录 
p = null; 


} 

// 修 改 一 个 产品 

public void editProduct(Product p,String name)t{ 
// 修 改 后 的 产品 


p.setName(name); 


/获得 是 否 可 以 创建 一 个 产品 


public boolean isCreateProduct()t{ 
return ispermittedCreate; 


} 
// 克 隆 一 个 产品 
public Product clone(Product p)t{ 
// 产 生 克 隆 事件 
return p.clone(); 


} 


仔细 看 看 工厂 类 ， 产 品 的 创建 、 修 改 、 遗 弃 、 克 隆 方法 都 很 们 
单 ， 但 有 一 个 方法 可 不 简单 一 一 isCreateProduct 方 法 ， 它 的 作用 是 告诉 
产品 类 “我 是 能 创建 产品 的 ”， 注 意 看 我 们 的 程序 ， 在 工厂 类 
ProductManager 中 定义 了 一 个 私有 变量 isCreateProduct， 该 变量 只 有 在 
工厂 类 的 createProduct 函 数 中 才能 设置 为 tue， 在 创建 产品 的 时 候 ， 产 
曲 类 Product 的 构造 画 数 要 求 传 递 工厂 对 象 ， 然 后 判断 是 否 能 够 创建 产 
品 ， 即 使 你 想 使 用 类 似 这 样 的 方法 : 


Product p = new Product(new ProductManager(),"abc"); 


也 是 不 可 能 创建 出 产品 的 ， 它 在 产品 类 中 限制 必须 是 当前 有 效 工 
三 才能 生产 该 产品 ， 而 且 也 只 有 有 效 的 工厂 才能 修改 产品 ， 看 看 产品 
类 的 canChanged 属 性 ， 只 有 它 为 tue 时 ， 产 品 才 可 以 修改 ， 那 怎么 才能 
为 true 呢 ?在 构造 函数 中 判断 是 否 可 以 为 mue。 这 束 类 似 工厂 要 创建 产 
品 了 ， 产 品 就 问 “你 有 权利 创建 我 吗 ? ”于 是 工厂 类 出 示 了 两 个 证 明 材 
料 证 明 目 己 可 以 创建 产品 : 一 是 “我 是 你 的 工厂 类 ”， 二 是 “我 的 
isCreateProduct 返 回 true， 我 有 权 创 建 "， 于 是 产品 就 被 创建 出 来 了 。 这 


种 一 个 对 象 只 能 由 固定 的 对 象 初始 化 的 方法 就 叫做 单 来 源 调用 (Single 
Call) 一 一 很 简单 ， 但 非常 有 用 的 方法 。 


注意 “采用 单 来 源 调用 的 两 个 对 象 一 般 是 组 合 关 系 ， 两 者 有 相同 
的 生命 期 ， 它 通常 运用 于 有 单 例 模 式 和 工厂 方法 模式 的 场景 中 。 


我 们 继续 往 下 分 析 ， 一 个 产品 新 建 要 触发 事件 ， 那 事件 是 什么 ? 
当然 也 是 一 个 对 象 了 ， 需 要 把 它 设 计 出 来 ， 仅 仅 有 事件 还 不 行 ， 还 要 
考虑 有 人 去 处 理 这 个 事件 ， 产 生 了 一 个 事件 不 可 能 没有 对 象 去 处 理 
吧 ? 如 果 是 这 样 那 事件 还 有 什么 意义 呢 ? 既然 要 去 处 理 ， 那 惑 需要 一 
个 通知 渠道 了 ， 于 是 观察 者 模式 准备 好 了 “。 好 ， 我 们 把 这 段 分 析 的 类 
图 也 画 出 来 ， 如 图 36-2 所 示 。 


<<interface>> 
Observer 


Observable 


攻 a ~、\ 
产品 事件 


-Product source; 
-ProductEventType type 


+Product getSource() 
+ProductEventType getEventType() 
-void notifyEventDispatch() 


EventDispatch 
-EventDispatch dispatch 


-EventDispatch() 
+EventDispatch getEventDispathc() 
+vold update(Observable o, Object arg) 


事件 通知 对 象 人 


<<enumeration>> 
ProductEventType 


+NEW_ PRODUCT!(1) 
+DEL PRODUCT(?) 
+EDIT PRODUCT(3) 
+CLONE PRODUCT(4) 


+ProductEventType(int _value) 
+imt getValue() 


图 36-2 观察 者 模式 处 理事 件 


在 该 类 图 中 ， 观 察 者 为 EventDispatch 类 ， 它 使 用 了 单 例 模式 ， 避 
免 对 象 膨胀 ， 但 同时 也 带 来 了 性 能 及 线程 安全 隐患 ， 这 点 需要 大 家 在 
实际 应 用 中 注意 ( 想 想 Spring 中 的 Bean 注 入 ， 默 认 也 是 单 例 ， 在 通常 的 
应 用 中 一 般 不 需要 修改 ， 除 非 是 较 大 并 发 的 应 用 ) 。 我 们 来 看 代码 ， 
先 来 看 事件 类 型 定义 ， 它 是 一 个 枚 举 类 型 ， 如 代码 清单 36-3 所 示 。 


代码 清单 36-3 事件 类 型 定义 


public enum ProductEventType { 
// 新 建 一 个 产品 
NEW_PRODUCT(1), 
// 删 除 一 个 产品 
DEL_PRODUCT(2 )， 
// 修 改 一 个 产品 
EDIT_PRODUCT(3), 
// 克 隆 一 个 产品 
CLONE_PRODUCT(4); 
private int value=0; 
private ProductEventType(int _value)t 

this.value = _value; 


} 

public int getValue(){ 
return this.value; 

} 


这 里 定义 了 4 个 事件 类 型 ， 分 别 是 新 建 、 修 改 、 删 除 以 及 克隆 ， 
较 简 单 。 我 们 再 来 看 产品 的 事件 ， 如 代码 清单 36-4 所 示 。 


代码 清单 36-4 产品 事件 


public class ProductEvent extends Observablef{ 
// 事 件 起 源 
private Product source; 
// 事 件 的 类 型 
private ProductEventType type; 
// 传 入 事件 的 源头 ， 默 认为 新 建 类 型 
public ProductEvent(Product p) { 
this(p,ProductEventType.NEW PRODUCT); 


} 
// 事 件 源头 以 及 事件 类 型 
public ProductEvent(Product p,ProductEventType _type)t{ 
this.source = p; 
this.type = _type; 
// 事 件 触 发 
notifyEventDispatch(); 


} 

// 获 得 事件 的 始作俑者 

public Product getSource(){ 
return source; 

} 


// 获 得 事件 的 类 型 
public ProductEventType getEventType(){ 
return this.type; 


} 
// 通 知事 件 处 理 中 心 
private void notifyEventDispatch(){ 


super.addObserver(EventDispatch.getEventDispatch()); 
super.setChanged(); 
super .notifyObservers(source); 


en 
方法 的 作用 是 明确 事件 的 观 绎 者 ， 并 同时 在 初始 化 时 通知 观察 着， 
在 有 参 构造 中 被 调用 。 我 们 再 来 看 事件 的 观察 者 ， 如 代码 清单 36-5 所 


修 ° 


代码 清单 36-5 事件 的 观察 者 


public class EventDispatch implements Observert 
// 单 例 模 式 
private final static EventDispatch dispatch = new 
EventDispatch(); 
// 不 允许 生成 新 的 实例 
private EventDispatch(){ 


} 

// 获 得 单 例 对 象 

public static EventDispatch getEventDispatch(){ 
return dispatch; 


} 
// 事 件 触 发 
public void update(Observable o, Object arg) { 


产品 和 事件 都 定义 出 来 了 ， 那 我 们 想 想 怎么 把 这 两 者 关联 起 来 ， 
产品 和 事件 是 两 个 独立 的 对 象 ， 两 者 都 可 以 独立 地 扩展 ， 用 什么 来 适 


应 它们 的 扩展 呢 ? 桥梁 模式 ! 两 个 不 相关 的 类 可 以 通过 桥 桨 模式 组 合 
出 稳定 、 健 壮 的 结构 ， 我 们 画 出 类 图 ， 如 图 36-3 所 示 。 


-Product source; -Strng name 
-ProductEventType type -boolean canChanged = false 


+ProductEvent(Product p) +String getName() 
+Product getSource() +Vvold setName(Strng name) 
+ProductEventType getEventType() +Product clone() 

-vold notifyEventDispatch() 


ProductManager 


图 36-3 桥梁 模式 实现 产品 和 事件 的 组 合 


看 着 不 像 桥 梁 模 式 ?” 看 看 桥梁 模式 的 通用 类 图 ， 然 后 把 抽象 化 角 
色 和 实现 化 角色 去 掉 看 看 ， 是 不 古 束 是 一 样 了 ? 各 位 可 能 要 说 了 人， 把 
抽象 化 角色 和 实现 化 角色 去 掉 ， 那 桥梁 模式 在 抽象 层次 耦合 的 优点 还 
怎么 体现 呢 ? 因为 我 们 采用 的 是 单个 产品 对 象 ， 没 有 必要 进行 抽象 化 
处 理 ， 读 者 大 要 按照 该 框架 做 扩展 开发 ， 该 部 分 是 肯定 需要 抽象 出 接 
口 或 抽象 类 的 ， 好 在 也 非常 简单 ， 只 要 抽取 一 下 就 可 以 了 。 这 样 考虑 
后 ， 我 们 的 ProductManager 类 职 增 加 一 个 功能 : 组 合 产品 类 和 事件 类 ， 
产生 有 意义 的 产品 事件 ， 如 代码 清单 36-6 所 示 。 


代码 清单 36-6 修正 后 的 产品 工厂 类 


public class Prodic Maneger { 
// 是 否 可 以 创建 一 个 产品 
private boolean isPpermittedCreate = false; 
// 建 立 一 个 产品 
public Product createProduct(String name)t{ 
// 首 先 修改 权限 ， 人 允许 创建 
isPermittedCreate = true; 
Product p = new Product(this,name ) ， 
// 产 生 一 个 创建 事件 
new ProductEvent(p,ProductEventType.NEW_ PRODUCT); 
return p; 


} 
// 废 弃 一 个 产品 
public void abandonProduct(Product p)t{ 
// 销 毁 一 个 产品 ， 例 如 删除 数据 库 记 录 
// 产 生 删 除 事件 
new ProductEvent(p,ProductEventType.DEL_ PRODUCT); 
p = null; 


} 
// 修 改 一 个 产品 
public void editProduct(Product p,String name)t{ 
// 修 改 后 的 产品 
p.setName(name); 
// 产 生 修改 事件 
new ProductEvent(p,ProductEventType.EDIT PRODUCT); 


} 

// 获 得 是 否 可 以 创建 一 个 产品 

public boolean isCreateProduct()t{ 
return ispermittedCreate; 


} 
// 克 隆 一 个 产品 
public Product clone(Product p)t{ 
// 产 生 克 隆 事件 
new ProductEvent(p,ProductEventType.CLONE_ PRODUCT); 
return p.clone(); 


在 每 个 方法 中 增加 了 事件 的 产生 机 制 ， 在 createProduct 方 法 中 增加 
了 创建 产品 事件 ， 在 editproduct 方 法 中 增加 了 修改 产品 事件 ， 在 


delProduct 方 法 中 增加 了 遗弃 产品 事件 ， 在 clone 方 法 中 增加 克隆 产品 事 
件 ， 而 且 每 个 事件 都 是 通过 组 合 产生 的 ， 产 品 和 事件 的 扩展 性 非常 优 


秀 。 


刚刚 我 们 次 完了 产品 和 事件 的 关系 处 理 ， 现 在 回 到 我 们 事件 的 观 
察 痢 ， 它 承担 看 非 第 重要 的 职责 。 我 们 知道 它 要 处 理事 件 ， 但 十 现在 
还 没有 想 好 怎么 实现 它 处 理事 件 的 update 方 法 ， 和 暂时 你 持 为 空 。 


我 们 继续 分 析 ， 这 么 多 的 事件 (现在 只 有 1 个 产品 类 ， 如 果 产 品类 
很 多 呢 ? 比 如 30 多 个 ) 不 可 能 每 个 产品 事件 都 写 一 个 处 理 者 吧 ， 对 于 
产品 事件 来 说 ， 它 最 希望 的 结果 就 是 我 通知 了 事件 处 理 者 (也 就 是 观 
察 者 模式 的 观察 者 ) ， 其 他 具体 怎么 处 理由 观察 者 来 解决 ， 那 现在 问 
题 是 观察 者 各 么 来 处 理 这 么 多 的 事件 呢 ? 事件 的 处 理 者 必然 有 N 多 

如 何 才能 通知 相应 的 处 理 者 来 处 理事 件 呢 ?一 个 事件 也 可 能 通知 多 个 
处 理 者 来 处 理 ， 并 且 一 个 处 理 者 处 理 完毕 还 可 能 通知 其 他 的 处 理 者 ， 

这 不 可 能 让 每 个 处 理 者 独 目 完成 这 样 “ 不 可 能 完成 的 任务 ”， 我 们 把 问 
题 的 示意 图 画 出 来 ， 如 图 36-4 所 示 。 


图 36-4 事件 处 理 示意 图 


看 到 该 示意 图 ， 你 了 立刻 就 会 想到 中 介 者 模式 。 是 的 ， 需 要 中 介 者 
模式 上 场 了 ， 我 们 把 EventDispatch 类 (嘿嘿 ， 为 什么 要 定义 成 Dispatch 
呢 ? 就 是 分 发 的 意思 ) 作为 事件 分 发 的 中 介 者 ， 事 件 的 处 理 者 都 是 具 
体 的 同事 类 ， 它 们 有 着 相似 的 行为 ， 都 是 处 理 产 品 事件 ， 但 是 又 有 不 


相同 的 逻辑 ， 每 个 同事 类 对 事件 都 有 不 同 的 处 理 行为 。 我 们 来 看 类 
图 ， 如 图 36-5 所 示 。 


在 类 图 中 ，EventDispatch 类 有 3 个 职责 。 
e 事件 的 观察 者 


作为 观察 者 模 式 中 的 观察 者 角色 ， 接 收 被 观察 期 望 完 成 的 任务 ， 
在 我 们 的 框架 中 束 是 接收 ProductEvent 事 件 。 


e 事件 分 发 阁 


作为 中 介 者 模式 的 中 介 者 角色 ， 它 担当 着 非常 重要 的 任务 一 一 分 
发 事件 ， 并 同时 协调 各 个 同事 类 〈 也 就 是 事件 的 处 理 者 ) 处 理事 件 。 


e 事件 处 理 者 的 管理 员 角 色 


不 是 每 一 个 事件 的 处 理 者 都 可 以 接收 事件 并 进行 处 理 ， 是 需要 获 
得 分 发 人 者 许可 后 才 可 以 ， 也 吏 是 说 只 有 事件 分 发 者 允许 它 处 理 ， 它 才 
能 处 理 。 


<<enumeration>> 
EventCustomType 


+NEWI(]) 


事件 处 理 者 的 类 型 


<<interface>> 
A 


EventCustomer 
-Vector customType 


+EventCustomer(EventCustomType _type) 
+void addCustomType(EventCustomType _type) 
+Vector<EventCustomType> getCustomType() 
+void exec(ProductEvent event) 


+DEL(?) 
+EDIT(3) 
+CLONE(4) 


EventDispatch 


-EventDispatch dispatch 


< -EventDispatch() 
+EventDispatch getEventDispathc() 
+void update(Observable o, Object arg) 
+void registerCustomer() 


图 36-5 采用 中 介 痢 模式 对 事件 进行 分 发 


事件 分 发 者 担当 了 这 么 多 的 职责 ， 那 是 不 是 与 单一 职责 原则 相 违 
育 了 ? 确实 如 此 ， 我 们 在 整个 系统 的 设计 中 确实 需要 这 样 一 个 角色 担 
任 这 么 多 的 功能 ， 如 果 强 制 细 分 也 可 以 完成 ， 但 是 会 加 大 代码 量 ， 同 
时 导致 系统 的 结构 复杂 ， 读 着 可 以 孝 虑 拆 分 这 3 个 职责 ， 然 后 再 组 合 相 
关 的 功能 ， 看 看 代码 量 是 如 何 翻 倍 的 。 


注意 ”设计 原则 只 是 一 个 理论 ， 而 不 是 一 个 囊 有 刻度 的 标尺 ， 因 
此 在 系统 设计 中 不 应 该 把 它 视 为 不 可 逾越 的 屏障 ， 而 古 应 该 把 它 看 成 
是 一 个 方 回 标 ， 尽 量 齐 守 ， 而 不 是 必须 恪守 。 


既然 事件 分 发 者 这么 重要 ， 我 们 整 仔细 人 研读 一 下 它 的 代码 ， 如 代 
码 清单 36-7 所 示 。 


代码 清单 36-7 事件 分 发 者 


public class EventDispatch implements Observer{ 

// 单 例 模 式 

private final static EventDispatch dispatch = new 
EventDispatch(); 

// 事 件 消费 者 

private Vector<EventCustomer> customer = new 
Vector<EventCustomer>(); 

// 不 允许 生成 新 的 实例 

private EventDispatch(){ 


} 

// 获 得 单 例 对 象 

public static EventDispatch getEventDispatch(){ 
return dispatch ; 


} 

// 事 件 触发 

public void update(Observable o, Object arg) { 
// 事 件 的 源头 
Product product = (Product)arg; 
// 事 件 


ProductEvent event = (ProductEvent )o; 
// 处 理 者 处 理 ， 这 里 是 中 介 者 模式 的 核心 ， 可 以 是 很 复杂 的 业务 逻辑 
for(EventCustomer e:customer){ 
// 处 理 能 力 是 否 匹 配 
for(EventCustomType t:e.getCustomType()){ 
if(t.getValue( )== 
event.getEventType().getVvalue())t{ 
e.exec(event); 
} 


上 
} 
// 注 册 事件 处 理 者 


public void registerCustomer(EventCustomer _customer)t{ 
customer.add(_customer ); 
} 


我 们 在 这 里 使 用 Vector 来 存储 所 有 的 事件 处 理 着 ， 在 update 方 法 中 
使 用 了 两 个 简单 的 for 循 环 来 完成 业务 逻辑 的 判断 ， 只 要 事件 的 处 理 者 
级 别 和 事件 的 类 型 相 匹 配 ， 束 调用 事件 处 理 首 的 exec 方 法 来 处 理事 件 ， 
该 逻辑 是 整个 事件 触发 涤 构 的 关键 点 ， 但 不 古 难 点 。 请 读者 注意 ,在 
设计 这 样 的 框架 前 ,一定 要 定义 好 消费 着 与 生产 着 之 间 的 搭配 问题 ， 
一 般 的 做 法 是 通过 xm] 文 件 类 或 者 IoC 容 器 配置 规则 ， 然 后 在 框架 启动 
时 加 载 并 驻 留 内 存 。 


EventCustomer 抽 象 类 负责 定义 事件 处 理 者 必须 具有 的 行为 ， 首 先 
是 每 一 个 事件 的 处 理 者 都 必须 定义 目 己 能 够 处 理 的 级 别 ， 也 就 是 通过 
构造 函数 来 定义 自己 的 处 理 能 力 ， 当 然 处 理 能 力 可 以 是 多 值 的 ， 也 怠 
是 说 一 个 处 理 者 可 以 处 理 多 个 事件 ， 然 后 各 个 事件 的 处 理 者 只 要 实现 
exec 方 法 就 可 以 了 ， 完 成 自己 对 事件 的 消费 处 理 即 可 。 我 们 先 来 看 抽象 
的 事件 处 理 者 ， 如 代码 清单 36-8 所 示 。 


代码 清单 36-8 抽象 的 事件 处 理 者 


public abstract class EventCustomer { 
// 容 纳 每 个 消费 者 能 够 处 理 的 级 别 
private Vector<EventCustomType> customType = new 
Vector<EventCustomType>(); 
// 每 个 消费 者 都 要 声明 自己 处 理 哪 一 类 别 的 事件 
public EventCustomer(EventCustomType _type)t{ 
addCustomType(_type); 


} 

// 每 个 消费 者 可 以 消费 多 个 事件 

public void addCustomType(EventCustomType _type)t{ 
customType.add(_type); 


} 
// 得 到 自己 的 处 理 能 


public Vector<EventCustomType> getCustomType(){ 
return customType; 


} 
// 每 个 事件 都 要 对 事件 进行 声明 式 消费 


public abstract void exec(ProductEvent event ) ; 


很 休 单 ， 我 们 定义 了 一 个 Vector 变 量 来 存储 处 理 者 的 处 理 能 力 ， 然 
后 通过 构造 函数 约束 于 类 必须 定义 一 个 目 己 的 处 理 能 力 。 在 代码 中 ， 
我 们 用 到 了 事件 处 理 类 型 枚 举 ， 如 代码 清单 36-9 所 示 。 


代码 清单 36-9 事件 处 理 枚 举 


public enum EventCustomType { 
// 新 建立 事件 
NEW(1), 
// 删 除 事件 
DEL(2), 
// 修 改 事件 
EDIT(3), 
// 克 隆 事件 
CLONE(4); 
private int value=0; 
private EventCustomType(int _value)t 
this.value = value; 


} 

public int getValue(){ 
return value; 

} 


我 们 在 系统 中 定义 了 3 个 事件 处 理 者 ， 分 别 是 乞丐 、 平 民 和 贵族 。 
乞丐 只 能 获得 别人 遗弃 的 物品 ， 平 民 消费 自己 生产 的 东西 ， 自 给 自 
足 ， 而 贵族 则 可 以 获得 精 修 的 产品 或 者 是 绿色 产品 (也 就 是 我 们 这 里 
的 克隆 产品 ， 不 用 自己 劳动 获得 的 产品 ) 。 我 们 先 看 乞丐 的 源 代 码 ， 
如 代码 清单 36-10 所 示 。 


代码 清单 36-10 乞丐 


public class Beggar extends EventCustomer { 
// 只 ~\ 能 处 理 被 人 遗弃 的 东西 

public Beggar(){ 
super (EventCustomType .DEL ) ; 


Q@override 
public void exec(ProductEvent event ) { 
// 事 件 的 源头 
Product p = event ,getSource() ; 
// 事 件 类 型 
ProductEventType type = event .getEVentType( ) ; 
System.out.println(" 乞 丐 处 理事 件 :"+p .getName() +" 销 毁 ， 
事件 类 型 ="+type ) ; 
} 


乞丐 在 无 参 构造 中 定义 了 目 己 只 能 处 理 删 除 的 事件 ， 然 后 在 exec 方 
法 中 定义 了 事件 的 处 理 逻 辑 ， 每 个 处 理 着 都 是 只 要 完成 这 两 个 方法 即 
可 ,我 们 再 来 看 平民 级 别 的 事件 处 理 首 ， 如 代码 清单 36-11 所 示 。 


代码 清单 36-11 平民 


public class Commoner extends EventCustomer { 
// 定 义 平民 能 够 处 理 的 事件 的 级 别 
public Commoner() { 
super (EventCustomType.NEW); 


Q@Override 

public void exec(ProductEvent event) { 
// 事 件 的 源头 
Product p = event ,getSource() ; 
// 事 件 类 型 
ProductEventType type = event.getEventType(); 
System.out.println(" 平 民 处 理事 件 :"+p .getName() +" 诈 和 9 

记 , 事件 类 型 ="+type); 
} 


} 


上 人 


平民 只 处 理 新 建立 的 事件 ， 其 他 事件 不 做 处 理 ， 我 们 再 来 看 贵族 
级 别 的 事件 处 理 者 ， 如 代码 清单 36-12 所 示 。 


代码 清单 36-12 贯 族 


public class Nobleman extends EventCustomer { 
// 定 义 贵 族 能 够 处 理 的 事件 的 级 别 
public Nobleman() { 
super (EventCustomType .EDIT); 
Super .addCustomType(EventCustomType.CLONE); 


@Override 
public void exec(ProductEvent event) { 
// 事 件 的 源头 
Product p = event ,getSource( ) ， 
// 事 件 类 型 
ProductEventType type = event .getEVentType( ) ; 
if(type.getValue() == 
EventCustomType.CLONE.getValue())t{ 
System.out.println(" 赏 族 处 理事 件 :"+p.getName() 
+" 克 隆 ,事件 类 型 ="+type ) 
}elsef 
System.out.printlLn(" 贵 族 处 理事 件 :"+p.getName( ) 
+" 修 改 ,事件 类 型 ="+type ) ; 
} 


} 


贵族 稍 有 不 同 ， 它 有 两 个 处 理 能 力 ， 能 够 处 理 修改 事件 和 克隆 事 
件 ， 同 时 在 exec 方 法 中 对 这 两 类 事件 分 别 进行 处 理 。 此 时 ， 读 者 可 能 会 
想到 另外 一 个 处 理 模 式 : 责任 链 模式 。 建 立 一 个 链 ， 然 后 两 类 事件 分 
别 在 链 上 进行 处 理 并 反馈 绪 采 。 读 着 可 以 参考 一 下 Servlet 的 过 滤 郁 
(Filter) 的 设计 ， 在 框架 平台 的 开发 中 可 以 采用 该 模式 ， 它 具有 非常 
好 的 扩展 性 和 稳定 性 。 


所 有 的 角色 都 已 出 场 ， 我 们 建立 一 个 场景 类 把 它们 串联 起 来 ， 如 
代码 清单 36-13 所 示 。 


代码 清单 36-13 场景 类 


public class Client { 
public static void main(String[] args) { 

// 获 得 事件 分 发 中 心 
EventDispatch dispatch = 

EventDispatch.getEventDispatch( ) ， 
// 接 受 乞 丐 对 事件 的 处 理 
dispatch.registerCustomer (new Beggar()); 
// 接 受 平民 对 事件 的 处 理 
dispatch.registerCustomer (new Commoner()); 
// 接 受 贵族 对 事件 的 处 理 
pe registerCustomer(new Nobleman( ) ) ; 
// 建 立 一 个 原子 弹 生 产 工 | 
aa factory = new ProductManager () ; 
// 制 造 一 个 产品 
System.out.printlLn("===== 模 拟 创 建 产 品 事件 ========" ) ; 
System,out,println(" 创 建 一 个 叫做 小 男孩 的 原子 弹 " ) ; 
Product p = factory.createProduct(" 小 男孩 原子 弹 "); 
// 修 改 一 个 产品 
System.out. println("\n===== 模 拟 修 改 产 品 事件 ========" ); 
System.out .println(" 把 小 男孩 原 于 弹 修改 为 胖 于 号 原子 弹 ")， 
factory.editProduct(p， "胖子 号 原子 弹 ")， 
// 再 克隆 一 个 原子 弹 
System.out .println("\n===== 模 拟 克隆 产品 事件 ========" ); 
System.out .println(" 克 隆 胖子 号 原子 弹 ")， 
Teo clone(p); 
// 遗 弃 一 个 产品 
System.out.println("NXn===== 模 拟 销毁 产品 事件 ========") ; 
System.out .print1ln(" 遗 弃 胖 子 号 原子 弹 " ) ， 
factory.abandonProduct(p); 


ww 


了 结果 如 下 所 示 : 


区 


册 


-==-- 模 拟 创建 产品 事件 ====--=- 


创建 一 个 叫做 小 男孩 的 原子 弹 


平民 处 理事 件 :小 男孩 原子 弹 诞生 记 , 事 件 类 型 =NEW_PRODUCT 


jn 
El 
琅 


===== 模 拟 修改 产品 事 


把 小 男孩 原子 弹 修改 为 胖子 号 原子 弹 


贵族 处 理事 件 :胖子 号 原子 弹 修 改 ,事件 类 型 =EDIT_PRODUCT 


| 
琅 


===== 模 拟 区 隆 产 品 事 


克隆 胖子 号 原子 弹 


贵族 处 理事 件 :胖子 号 原子 弹 克 隆 ,事件 类 型 =CLONE_PRODUCT 


乞丐 处 理事 件 :胖子 号 原子 弹 销毁 ,事件 类 型 =DEL_PRODUCT 


我 们 的 事件 处 理 框 架 已 经 生效 了 ， 有 行为 ， 殊 产生 事件 ， 并 有 处 
理事 件 的 处 理 者 ， 并 且 这 三 者 都 相互 解 稍 ， 可 以 独立 地 扩展 下 去 。 比 
如 ， 想 增加 处 理 者 ， 没 有 问题 ， 建 立 一 个 类 继承 EventCustomer， 然 后 
注册 到 EventDispatch 上 ， 束 可 以 进行 处 理事 件 了 ;， 想 扩展 产品 ， 没 问 
题 ? 需要 稍稍 修改 一 下 ， 首 先 抽取 出 产品 和 事件 的 抽象 类 ， 然 后 再 进 
行 扩展 即 可 。 


36.2 混 编 小 结 


该 事件 触发 框架 结构 清晰 ， 扩 展 性 好 ， 读 者 可 以 进行 抽象 化 处 理 
后 应 用 于 实际 开发 中 。 我 们 回头 看 看 在 这 个 案例 中 使 用 了 哪些 设计 模 


e 工厂 方法 模式 


负责 产生 产品 对 象 ， 方 便 产 品 的 修改 和 扩展 ， 并 且 实 现 了 产品 和 
工厂 的 紧 籼 合 ， 避 人 免 产 品 随意 被 创建 而 无 触发 事件 的 情况 发 生 。 


e 醋 梁 模式 


在 产品 和 事件 两 个 对 象 的 关系 中 我 们 使 用 了 桥梁 模式 ， 如 此 设计 
后 ， 两 者 者 可 以 目 由 地 扩展 (前 提 是 需要 抽取 抽象 化 ， 而 不 会 破坏 原 
有 的 封闭 


e 观察 者 模式 


观察 者 模式 解决 了 事件 如 何 通 知 处 理 者 的 问题 ， 而 且 观 察 者 模式 
还 有 一 个 优点 是 可 以 有 多 个 观察 者 ， 也 就 古 我 们 的 架构 是 可 以 有 多 层 
级 、 多 分 类 的 处 理 者 。 想 重新 扩展 一 个 新 类 型 (新 接口 ) 的 观察 者 ? 
没有 问题 ， 扩 展 ProductEvent 即 可 。 


e 中 介 者 模式 


事件 有 了 ， 处 理 者 也 有 了 ， 这 些 都 会 发 生变 化 ， 并 且 处 理 者 之 间 
也 有 耦合 关系 ， 中 介 者 则 可 以 完美 地 处 理 这 些 复杂 的 关系 。 


我 们 再 来 思考 一 下 ， 如 采 我 们 要 扩展 这 个 框 杂 ， 可 能 还 会 用 到 什 
么 模式 ? 首先 是 责任 链 模式 ， 它 可 以 帮助 我 们 解决 一 个 处 理 者 处 理 多 
个 事件 的 问题 ， 其 次 是 模 板 方 法 模式 ， 处 理 者 的 局 用 、 停 用 等 ， 都 可 
以 通过 模板 方法 模式 来 实现 ， 再 次 是 装饰 模式 ， 事 件 的 包 竣 、 处 理 痢 
功能 的 强化 都 会 用 到 装饰 模式 。 当 然 了 ， 我 们 还 可 能 用 到 其 他 的 模 
式 ， 只 要 能 够 很 好 地 解决 我 们 的 困境 ， 那 惑 好 好 使 用 吧 ， 这 也 是 我 们 
学 习 设 计 模 式 的 目的 。 


第 37 章 


第 38 章 


MVC 框 架 
新 模式 


第 37 章 “MVC 框 架 


37.1 MVC 框 架 的 实现 


相信 这 本 书 的 读者 对 Struts 的 使 用 是 得 心 应 手 了 ， 也 明白 MVC 框 架 
有 诸如 视图 与 逻辑 解 厢 、 灵 活 稳定 、 业 务 逻 辑 可 重用 等 优点 ， 而 且 还 
对 其 他 的 MVC 框 架 (例如 JSF、Spring MVC、WebWork) 也 了 解 一 
点 。SSH (Struts+Spring+Hibernate) 框架 是 Java 项 目 常用 的 框架 ， 作 为 
一 个 Java 开 发 人 员 ， 应 该 对 SSH 框 架 很 熟悉 了 ! 我 们 今天 就 学 Struts 怎 
么 用 ! 我 们 要 讲 的 是 MVC 框 架 如 何 设计 ， 你 可 以 设计 一 个 新 的 MVC 框 


架 与 Struts 抗 衡 。 


在 开始 设计 MVC 框 架 前 ， 首 移 要 对 MVC 框 架 做 一 个 简单 的 介绍 。 
MVC (Model ViewController) 的 中 文 名 称 叫做 模型 视图 控制 右 模 型 ， 
束 古 因为 它 的 英文 名 子 太 流 行 了 ， 中 文 名 字 反 而 个 忽略 了 。 它 道生 于 
20 世 纪 80 年 代 ， 原 本 是 为 桌面 应 用 程序 建立 起 来 的 一 个 框架 ， 现 在 反 
而 在 Web 应 用 中 大 放 异 彩 (其 实 也 可 以 把 B/S 认为 是 C/S 的 瘦 化 结构 )， 
MVC 框 架 的 目的 是 通过 控制 器 C 将 模型 M (代表 的 是 业务 数据 和 业务 逻 
辑 ) 和 视图 V (人 机 交互 的 界面 ) 实现 代码 分 离 ， 从 而 使 同一 个 逻辑 或 
行为 或 数据 可 以 具有 不 同 的 表现 形式 ， 或 者 是 同样 的 应 用 逻辑 共 译 相 
同 、 不 同 视图 。 比 如 ， 可 以 用 焉 浏览 器 访问 某 应 用 网 站 (页 面 格式 遵 


守 HTML 标准 ) ， 也 可 以 用 手机 通过 WAP 浏 览 器 访问 (页 面 格式 遵守 
WML 格 式 ) ， 对 MVC 框 架 来 说 ， 后 台 的 程序 〈 也 就 是 模型 ) 不 用 做 任 
何 修改 ， 只 是 使 用 的 视图 不 同 而 已 。MVC 框 架 如 图 37-1 所 示 。 


控制 妖 


(Controller) 


图 37-1 MVC 框 架 示意 图 


该 框架 是 Model2 的 结构 。MVC 框 架 有 两 个 版 本 ， 一 个 是 Model1l， 
也 就 是 MVC 的 第 一 个 版 本 ， 它 的 视图 中 存在 着 大 量 的 流程 控制 和 代码 
开发 ， 也 就 是 控制 器 和 视图 还 具有 部 分 的 而 合 。 也 有 人 不 认为 Modell 
属于 MVC 框 殿 ， 那 也 说 得 通 ， 因 为 在 JSP 页 面 中 融合 了 控制 器 和 视图 的 
功能 ， 这 其 实 就 是 早期 的 开发 模式 ， 开 发 一 堆 的 JSP 页 面 ， 然 后 再 开发 
一 堆 的 JavaBean，JavaBean 葡 是 模型 了 ， 它 只 是 把 JSP 和 JavaBean 拆 分 
开 了 “。Model2 版 本 则 提倡 视图 和 模型 的 彻底 分 离 ， 视 图 仅仅 负责 
服务 ,不 再 参与 业务 的 行为 和 数据 处 理 。 我 们 举例 来 说 明 MVC 框 架 是 


如 何 图 37-1 MVC 框 架 示意 图 控制 器 (Controller) 视图 (View) 模型 


(Model) 第 37 章 运行 的 。 


在 做 Web 开 发 和 时， 例如 开发 一 个 数据 展示 界面 ， 从 一 张 表 中 把 数据 
全 部 读 出 ， 然 后 展示 到 页 面 上 ， 也 是 一 个 简单 的 表格 ， 其 中 页 面 展 示 
的 格式 束 是 视图 V， 怎 么 从 数据 库 中 取得 数据 则 是 模型 M， 那 控制 器 C 
是 做 什么 的 呢 ? 它 负责 把 接收 的 浏览 器 的 请 求 转发 通知 模型 M 处 理 ， 
然后 组 合 视图 V， 最 终 反 馈 一 个 市 数据 的 视图 到 用 户 端 ， 数 据 处 理 流程 
如 图 37-2 所 示 。 


返回 浏览 器 @ mahi 


\ [一 + 站 _ 到 
wii i 委托 模型 处 理 @ 
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图 37-2 MVC 框 架 的 逻辑 流 


浏览 器 通过 HTTP 协 议 发 出 数据 请 求 Y， 由 控制 絮 接 收 请 求 ， 通 过 
路 径 (2) 委 托 给 数据 模型 处 理 ， 模 型 通过 与 逻辑 层 和 持久 层 的 交互 (路 
人 径 (3X4)) ， 把 处 理 结果 反馈 给 控制 器 (路径 (5)) ， 控 制 器 根据 结果 组 装 
视图 (路径 (6XD) ， 并 最 终 反馈 给 浏览 器 可 以 接受 的 HTML 数 据 (路 人 径 
人) 。 整 体 MVC 框 架 还 是 比较 简单 的 ， 但 它 带 来 的 优点 非常 多 。 


e 高 重用 性 


一 个 模型 可 以 有 多 个 视图 ， 比 如 同样 是 一 批 数据 ， 可 以 是 柱状 展 
示 ， 也 可 以 古 条 形 展 示 ， 还 可 以 是 波形 展示 。 同 样 ， 多 个 模型 也 可 以 
共享 一 个 视图 ， 同 样 是 一 个 登录 界面 ， 不 同 用 户 看 到 的 菜单 数量 ( 模 
型 中 的 数据 ) 不 同 ， 或 者 不 同业 务 权限 级 别 的 用 户 在 同一 个 视图 中 展 


修 ° 


e 低 帮 合 


因为 模型 和 视图 分 离 ， 两 者 没有 耦合 关系 ， 所 以 可 以 独立 地 扩展 
和 修改 而 不 会 产生 相互 影响 。 


e 快速 开发 和 便捷 部 署 


模型 和 视图 分 离 ， 可 以 使 各 个 开发 人 员 自 由 发 挥 ， 做 视图 的 人 员 
和 开发 模型 的 人 员 可 以 制订 自己 的 计划 ， 然 后 在 控制 器 的 协作 下 实现 


完整 的 应 用 逻辑 。 


MVC 框 淋 还 有 很 多 优点 ， 本 章 主要 不 是 讲解 MVC 技 术 ， 主 要 是 通 
过 讲解 设计 MVC 框 架 来 说 明 设计 模式 该 皇 么 应 用 ， 所 以 想 了 解 更 详细 
的 MVC 框 架 信 息 请 自行 查阅 资料 。 


37.1.1 MVC 的 系统 架构 


我 们 设计 的 MVC 框 架 包 含 以 下 模块 :核心 控 制 絮 
(FilterDispatcher) 、 拦 截 器 (Interceptor) 、 过 滤器 (Filter) 、 模 型 
管理 器 (Model Action) 、 视 图 管理 器 (View Provider) 等 ， 基 本 上 一 
个 MVC 框 架 上 常用 的 功能 我 们 都 具备 了 ， 系 统 架 构 如 图 37-3 所 示 。 


核心 控制 器 


(aa | ss | 


图 37-3 MVC 系 统 架 构 


各 个 模块 的 职责 如 下 : 
e 核心 控制 邵 


MYVC 框 架 的 入 口 ， 负 责 接收 和 反馈 HTTP 请 求 。 


e 过 滤 需 


Servlet 容 右 内 的 过 滤 右 ， 实 现 对 数据 的 过 滤 处 理 。 由 于 它 古 容 此 内 
的 ， 因 此 必须 依 徘 容 紫 才 能 运行 ， 它 是 容器 的 一 项 功能 ， 与 容 右 居 忌 
相关 ， 本 章 就 不 详细 讲述 了 。 


e 拦截 需 


对 进出 模型 的 数据 进行 过 滤 ， 它 不 依赖 系统 容器 ， 只 过 滤 MVC 框 
架 内 的 业务 数据 。 


提供 一 个 模型 框架 ， 该 框 染 内 的 所 有 业务 操作 部 应 该 是 无 状态 
的 ， 不 关心 容器 对 象 ， 例 如 Session、 线 程 池 等 。 


e 视图 管理 厂 
管理 所 有 的 视图 ， 例 如 提供 多 语言 的 视图 等 。 
e 辅助 工具 


它 其 实 就 是 一 大 堆 的 辅助 管理 工具 ， 比 如 文件 管理 、 对 象 管理 


类 


在 我 们 的 MVC 框 架 中 ， 核 心 控制 器 是 最 重要 的 ， 我 们 就 先 从 它 着 
手 。 核 心 控制 器 使 用 了 Servlet 容 器 的 过 滤器 技术 ， 需 要 编写 一 个 过 滤 
器 ， 所 有 进入 MVC 框 架 的 请 求 都 需要 经 过 核心 控制 器 的 转发 ， 类 图 如 
图 37-4 所 示 。 


IActionDispatcher 


+String actionInovke() 


Value Manager 
| 
+String getViewPath() 
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+void doFilter() 
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> 


- 人 二 生 网 
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+void info(String log) 


图 37-4 核心 控制 器 类 图 


由 于 类 网 中 的 部 分 输入 参数 类 型 较 长 ， 省 略 了 ， 请 读者 仔细 看 代 
码 。 首 先 | 阅读 FilterDispatcher 代 码 ， 如 代码 清单 37-1 所 示 。 


代码 清单 37-1 核心 控制 器 


public class FilterDispatcher implements Filter { 
// 定 义 一 个 值 栈 辅 助 类 
private ValueStackHelper valueStackHelper = new 
ValueStackHelper(); 
// 应 用 IActionDispatcher 
IActionDispather actionDispatcher = new ActionDispatcher(); 
//servlLet 销 毁 时 要 做 的 事情 
public void destroy() { 


} 
// 过 滤器 必须 实现 的 方法 


public void doFilter(ServletRequest request, 

ServletResponse response, 

FilterChain chain) throws IOException, 
ServletException { 

// 转 换 为 HttpServletRequest 

HttpServletRequest req = (HttpServletRequest)request,; 

HttpServletResponse res = 
(HttpServletResponse)response; 

// 传 递 到 其 他 过 滤器 处 理 

chain.doFilter(req, res); 

// 获 得 从 HTTP 请 求 的 ACTION 名 称 

String actionName = getActionNameFromURI(req); 

// 对 ViewManager 的 应 用 

ViewManager viewManager = new ViewManager(actionName); 

// 所 有 参数 放 入 值 栈 

ValueStack valueStack = 
valueStackHelper .putIntoSstack(req); 

// 把 所 有 的 请 求 传递 给 ActionDispatcher 处 理 

String result 
=actionDispatcher.actionInvoke(actionNanme); 

String viewPath = viewManager .getViewPath(result); 

// 直 接 转 向 

RequestDispatcher rd = 
req.getRequestDispatcher(viewPath); 

rd.forward(req, res); 


public void init(FilterConfig arg0) throws ServletException 


{ 
/* 
* 1、 检 查 XML 配 置 文件 是 否 正 确 
* 2、 启 动 监控 程序 ， 观 察 配置 文件 是 否 正确 
*/ 
} AN ee Bh 
// 通 过 ur1 获 得 actionName 
private String getActionNameFromURI(HttpServletRequest redq) 
{ 


String path = (String) req.getRequestURI(); 

String actionName = 
path.substring(path.JlastIndexof("/") + 1, 

path.1lastIindexof(".")); 

return actionName; 


我 们 按照 系统 的 执行 顺序 来 讲解 ， 首 先 在 容器 的 配置 文件 中 需要 
配置 该 过 滤 如 ， 以 tomcat 为 例 ， 配 置 如 代码 清单 37-2 所 示 。 


代码 清单 37-2 核心 控制 右 的 配置 


<?xml1 version="1.0" encoding="UTF-8"?> 

<web-app> 

<filter> 
<display-name>FilterDispatcher</display-name> 
<filter-name>FilterDispatcher</filter-name> 
<filter-class>{ 包 名 }.FilterDispatcher</filter-class> 

</filter> 

<filter-mapping> 
<filter-name>FilterDispatcher</filter-name> 
<url-pattern>*.do</url-pattern> 
</filter-mapping> 

</web-app> 


在 这 里 定义 了 对 所 有 以 .do 结尾 的 请 求 进行 拦截 ， 拦 截 后 由 
FilterDispatcher 的 doFilter 方 法 处 理 。 过 滤 絮 是 在 局 动 时 目 动 初始 化 ， 初 
台 化 完毕 后 立刻 调用 inti 方 法 ， 在 init 方 法 中 我 们 做 了 两 件 事情 。 


e 检查 XML 配置 文件 


所 有 的 Action 与 视图 的 对 应 天 系 是 在 配置 文件 中 配置 的 ， 因 此 奉 配 
置 文 件 出 错 ， 该 应 用 应 该 停止 响应， 这 束 需 要 在 局 动 时 对 XML 文 件 进 


行 完整 性 检查 和 语法 分 析 。 


e 局 动 监视 紫 


配置 文件 随时 都 可 以 修改 ， 但 是 它 修改 后 不 应 该 需要 重新 启动 应 
用 才能 生效 ， 否 则 对 系统 的 正常 运行 有 非常 大 的 影响 ， 因 此 这 里 要 使 
用 到 Listener (监听 ) 行为 了 。 


init 方 法 需要 做 的 这 两 件 事 情 是 非常 重要 的 ， 而 且 都 还 包含 了 几 种 
不 同 的 设计 模式 。 首 先 我 们 来 看 检查 XML 配置 文件 如 何 实现 。 先 看 我 
们 定义 的 XML 格式 (框架 中 应 该 定义 一 个 DID 文件 ，XML 文 件 的 模 
板 ， 读 者 可 以 自行 实现 ) ， 如 代码 清单 37-3 所 示 。 


代码 清单 37-3 XML 配置 文件 


<?xml] version="1.0" encoding="UTF-8"?> 
<mvc> 
<action name="loginAction" class="{ 类 名 全 路 径 }" 
method="execute"> 
<result name="success">/index2.jsp</result> 
<result name="fail">/index.jsp</result> 
</action> 
</mvc> 


读者 思考 一 下 该 怎么 检查 这 个 XML 文 件 ， 有 两 个 不 同 的 检查 策 
略 : 一 是 检查 XML 文 件 的 语法 是 否 正 确 ; 二 是 框架 逻辑 检查 ， 这 是 什 
么 意思 呢 ? 比如 我 们 在 XML 文件 中 配置 了 一 个 类 A， 它 只 有 一 个 方法 
methodA， 在 method 中 编写 的 配置 文件 为 method="methoda"， 方 法 名 写 
背 了 ， 那 这 样 的 配置 是 肯定 不 能 运行 的 ， 需 要 框架 逻辑 检查 把 它 揪 出 
来 。 这 两 种 不 同 的 算法 是 完全 可 以 替换 的 ， 而 且 很 有 必要 替换 ， 逮 辑 
检查 在 应 用 启动 的 时 候 需 要 对 所 有 的 类 进行 过 滤 处 理 ， 牺 牲 的 是 效 
率 ， 这 在 测试 机 上 没有 问题 ， 在 生产 机 上 要 花 20 分 钟 才能 把 一 个 应 用 


局 动 起 来 ， 在 分 秒 必 和 争 的 业务 系统 中 这 古 不 允许 的 ， 因 此 整 要 求 该 算 
法 可 以 退休 ， 想 用 的 时 候 (测试 机 环境 ) 就 用 ， 不 想 用 的 时 候 (生产 
环境 ) 就 不 用 ， 想 到 什么 模式 了 吗 ? 策略 模式 ， 这 两 个 算法 都 是 对 同 
样 的 源 文件 进行 检查 ， 只 是 算法 不 同 ， 当 然 可 以 相互 车 换 了 。 类 图 比 
较 人 简单 ， 束 不 再 画 了 ， 我 们 直接 看 代码 ， 抽 象 策 略 如 代码 清单 37-4 所 


修 ° 


代码 清单 37-4 XML 文 件 校 验 


public interface IXmlValidate { 
// 只 有 一 个 方法 ， 检 查 XML 是 否 符合 条 件 
public boolean validate(String xmlPath ) ; 


根据 一 个 指定 的 路 径 ， 对 XML 进行 校 验 ， 返 回 校 验 结果 。 普 通 
XML 校 验 如 代码 清单 37-5 所 示 。 


代码 清单 37-5 普通 XML 校 验 


public class CommonXm1lValidate implements IXmlValidate { 
//XML 语 法 检查 ， 比 如 是 否 少 写 了 一 个 结束 标志 
public boolean validate(String xmlPath) { 
return false; 
} 


由 于 读 写 XML 文件 一 般 使 用 DOM4J 或 者 JDOM ， 都 提供 对 XML 文 
件 的 语法 校 验 功 能 ， 不 符合 XML 语法 (比如 一 个 节点 少 写 了 结束 标志 
</node) 的 文件 是 不 能 解析 的 ， 读 者 可 以 在 自己 编写 框架 时 使 用 该 类 型 
工具 。 


框 以 的 逻辑 算法 如 代码 清单 37-6 所 示 。 


代码 清单 37-6 框 染 逻辑 校 验 


public class LogicxmlValidate implements IXm]lValidate { 
// 检 查 xmlPath 是 否 符 合 逻 辑 ， 比 如 不 会 出 现 一 个 类 中 没有 的 方法 
public boolean validate(String xmlPath) { 
return false; 
} 


逻辑 校 验 相对 比较 复杂 ， 它 的 逻辑 流程 如 下 : 
e 读 取 XML 文 件 。 


e 使 用 反射 技术 初始 化 一 个 对 象 【配置 文件 中 的 class 属 性 值 )。 


e 丛 得 坪 否 存在 配置 文件 中 配置 的 方法 。 

e 检查 方法 的 返回 值 是 否 是 String， 并 且 无 输入 参数 ， 同 时 必须 继 
承 指 定 类 或 接口 。 

逻辑 校 验 需 要 把 所 有 的 对 象 都 初始 化 一 肖 ， 在 Action 类 较 多 的 情况 


下 ， 效 率 较 低 ， 但 它 可 以 提前 发 现 出 现 访 问 异 第 的 情况 ， 把 问题 解决 
在 萌芽 状态 。 我 们 继续 来 看 两 个 策略 的 场景 类 ， 如 代码 清单 37-7 所 示 。 


代码 清单 37-7 策略 的 场景 类 


public class Checker { 
// 使 用 哪 一 个 策 E 
private IXmlValidate validate; 


//xm1l 配 置 文 件 的 路 径 


String xmlPath; 


// 构 造 画 数 传递 
public Checker (IXmlValidate _vValidate){ 
this.validate = validate; 


} 
public void setxXmlPath(String _xmlPath)t{ 
this.xmlPath = _xmlPath; 


} 
// 检 查 
public boolean check(){ 
return validate.validate(xmlPath); 
} 


与 通用 策略 模式 稍 有 不 同 ， 每 个 模式 在 实际 应 用 环境 中 都 有 其 个 
性 ， 很 少 出 现 完全 照搬 一 个 模式 的 情况 ， 有 灵活 应 用 设计 模式 才 生 天 
键 。 


在 FilterDispatcher 的 init 方 法 中 ， 我 们 刚刚 说 它 有 两 个 职责 : 第 一 个 
职责 是 XML 文 件 校 验 ， 这 个 我 们 完成 了 ;第 二 个 职责 是 局 动 监 控 程 
序 。 问 题 是 要 监控 什么 呢 ? 监控 XML 有 没有 被 修改 ， 如 果 修 改 了 就 立 
刻 通 知 校 验 程序 对 它 进行 校 验 。 这 束 又 用 到 了 观察 者 模式 : 发 现 文件 
被 修改 ， 它 立刻 通知 检查 者 处 理 ， 该 片段 的 类 图 如 图 37-5 所 示 。 


图 37-5 XML 文件 监控 类 图 


为 什么 要 在 这 里 定义 一 个 Watchable 接 口 呢 ? 它 表 示 所 有 可 以 监视 
的 资源 ， 比 如 数据 库 、 日 志文 件 、 和 磁盘 空间 等 。 我 们 来 看 代码 ， 监 听 
接口 如 代码 清单 37-8 所 示 。 


代码 清单 37-8 监听 接口 


public interface Watchable { 
// 监 听 
public void watch( ); 


文件 监听 着 是 观 绎 者 模式 的 被 观 察 着 ， 它 一 旦 发 现 文 件 发 生变 化 
立刻 通知 观察 者 ， 如 代码 清单 37-9 所 示 。 


代码 清单 37-9 文件 监听 者 


public class Filewatcher extends Observable implements 
watchablef{ 
// 是 否 要 重新 加 载 XML 文 件 


private boolean isReload = false; 


// 启 动 监视 
public void watch(){ 


// 启 动 一 个 线程 ， 每 隔 15 秒 扫描 一 下 文件 ， 发 现 文件 日 期 被 修改 ， 立 刻 通 
知 观察 者 
Super .addobserver(new Checker()); 
Super ,SetChanged() ， 
super .notifyObservers(isReload); 
} 
} 


由 于 框 染 是 在 操作 系统 之 上 运行 的 ， 文 件 变 化 时 操作 系统 是 不 会 
通知 应 用 系统 的 ， 因 此 我 们 能 做 的 束 是 局 动 一 个 线程 监视 一 批文 件 ， 
发 现 文件 改变 了 ， 立 刻 通知 相关 的 处 理 者 ， 它 虽然 有 时 间 和 延迟， 但 对 
于 一 个 应 用 框架 来 说 是 非常 有 必要 的 ， 避 免 了 重 局 应 用 才能 使 配置 生 
效 的 情况 。 


谈 者 可 能 很 疑惑 ， 这 种 死 循 环 的 监控 方式 会 不 会 对 性 能 产生 影 


啊 ， 答 案 生 不 会 ! 为 什么 呢 ? 


对 得 一 个 文件 的 时 间 一 般 是 毫秒 级 的 ， 相 对 于 我 们 设置 的 运行 周 
期 (比如 15 秒 执行 一 次 ) 是 一 个 非常 微小 的 运行 时 间 ， 对 应 用 不 会 产 
生 任 何 影响 。 大 家 都 在 使 用 Log4j 进 行 日 志 处 理 ， 它 有 一 个 线程 是 每 5 
秒 检 查 一 次 日 志 是 否 满 ， 大 家 觉得 性 能 滨 影响 了 吗 ? 基本 上 性 能 影响 


可 以 忽略 不 计 。 


由 于 Checker 还 要 作为 观察 者 ， 因 此 它 要 实现 Observer 接口 ， 同 时 
实现 update 方 法 ， 如 代码 清单 37-10 所 示 。 


代码 清单 37-10 修正 后 的 检查 者 


public class Checker implements Observer1{ 
public void update(Observable arg90, Object arg1) { 
// 检 查 是 否 符合 条 件 


arg1 = check(); 


到 此 为 止 ， 我 们 把 init 方 法 已 经 讲解 完毕 ， 它 是 在 容器 初始 化 时 调 
用 。 有 一 个 HITP 请 求 发 送 过 来 ， 容 器 调用 我 们 编写 的 doFilter 方 法 。 仔 
细 看 一 下 我 们 的 代码 ， 其 中 有 这 样 一 句 话 : Chain.doFilter(req,res)， 这 
句 话 是 什么 意思 呢 ? 是 说 让 后 续 的 过 滤器 先 运 行 ， 等 它们 运行 完毕 后 
该 过 滤器 再 运行 ， 应 该 想到 这 是 一 个 责任 链 模 式 ， 它 的 类 型 是 
FilterChain。Servlet 容 需 把 所 有 的 过 滤器 组 合 在 一 起 形成 了 一 个 过 滤器 
链 ， 它 是 怎么 做 到 的 呢 ? 容器 局 动 的 时 候 ， 把 所 有 的 过 滤 需 都 初始 化 
完毕 ， 然 后 根据 它们 在 web.xml 中 的 配置 顺序 ， 从 上 疝 下 组 装 一 个 过 渡 
器 链 。 注 意 所 有 的 过 滤器 都 必须 实现 Filter 接 口 ， 这 是 建立 过 滤器 链 的 
目 要 前 提 。 


我 们 再 回 过 头 来 仔细 看 看 类 图 ， 是 不 是 有 点 熟悉 ? 对， 类 似 于 中 
介 者 模式 ， 我 们 并 没有 把 中 介 者 传递 到 各 个 同事 类 ， 只 是 我 们 采用 中 
介 才 模式 的 思想 ， 把 中 介 者 的 职责 分 发 出 去 由 各 个 同事 类 来 处 理 。 


37.1.2 模型 管理 需 


模型 管理 右 是 整个 MVC 框 架 的 难点 ， 在 这 里 我 们 会 看 到 非常 多 的 
设计 模式 。 我 们 在 核心 控制 絮 的 类 图 中 看 到 有 一 个 IActionDispatcher 接 


口 ， 筷 实现 的 模型 行为 分 发 是 一 个 门面 模式 ， 如 代码 清单 37-11 所 示 。 


代码 清单 37-11 模型 行为 分 发 接口 


public interface IActionDispather { 
// 根 据 Action 的 名 字 ， 返 回 处 理 结果 


public String actionInvoke(String actionName ) ; 


它 的 职责 非常 简单 ， 得 到 actionName 就 执行 ， 熟 悉 Struts 的 读者 可 
能 很 清楚 这 个 方法 是 非常 复杂 的 ， 它 要 从 配置 文件 中 找到 执行 对 象 ， 
然后 执行 方法 ， 还 要 考虑 值 栈 、 异 常 等 ， 非 常 复 杂 。 我 们 这 里 就 有 一 
个 方法 ， 它 对 外 提供 一 个 门面 ， 所 有 的 访问 部 是 通过 该 门面 来 完成 ， 
其 实现 类 如 代码 清单 37-12 所 示 。 


代码 清单 37-12 模型 分 发 实现 


public class ActionDispather implements IActionDispather { 
// 需 要 执行 的 Action 
private ActionManager actionManager = new ActionManager(); 
// 拦 截 器 链 
private ArrayList<Interceptors> listInterceptors = 
InterceptorFactory.createInterceptors(); 
public String actionInvoke(String actionName) { 
// 前 置 拦截 器 
return actionManager .execAction(actionName ) ， 


// 后 置 拦截 器 


它 是 一 个 非常 简单 的 类 ， 对 外 部 提供 统一 封装 好 的 行为 。 模 型 管 
理 右 的 类 图 如 图 37-6 所 示 。 


首 移 说 ActionManager 类 ， 它 负责 管理 所 有 的 行为 类 Action， 那 丈 
必须 定义 一 个 行为 类 的 接口 或 抽象 类 ， 如 代码 清单 37-13 所 示 。 


代码 清单 37-13 抽象 Action 


public abstract class ActionSupport { 
public final static String SUCCESS = "success",，; 
public final static String FAIL = "fail"; 
// 默 认 的 执行 方法 
public String execute()t{ 
return SUCCESS,; 


} 
<<interface>> 
IActionDispather 
ActionManager ActionDispather 
| IE 
| | I > | 


ActionSupport 


Interceptors 
| 
| 


\ 


InterceptorFactory| ~、 


+void execte() 


Interceptor AbstractInterceptor 
Eo===== = 一 
| | | 


图 37-6 模型 管理 妖 类 图 


抽象 的 ActionSupport 类 看 起 来 很 简单 ， 其 实 它 可 不 简单 ， 所 有 的 
模型 行为 都 继承 该 类 ， 它 之 所 以 提供 一 个 默认 的 execute 方 法 ， 是 因为 
在 xml 的 配置 文件 中 ， 可 以 省 略 掉 method="XXX'" 这 人 句 话 ， 默 认 就 是 调 
用 该 方法 。 它 还 有 一 个 非常 重要 的 行为 : 对 象 映 映 ， 把 HTTP 传 递 过 来 
的 字符 串 映 射 到 一 个 业务 对 象 上 ， 我 们 会 在 值 栈 中 详细 讲解 。 


读者 可 能 很 疑惑 ，Action 的 操作 是 需要 获得 环境 数据 的 ， 比 如 
HTTPServletRequest 上 数据 ， 还 有 系统 中 的 Session 数 据 ， 单 单一 个 
ActionManager 如 何 获得 这 些 数据 呢 ? 通过 值 栈 ， 在 值 栈 中 保存 着 该 
Action 需 要 的 所 有 数据 。 


我 们 再 来 看 ActionManager 类 ， 如 代码 清单 37-14 所 示 。 


代码 清单 37-14 Action 管 理 类 


public class ActionManager { 

// 执 行 Action 的 指定 方法 

public String execAction(String actionName)t{ 
return null; 


束 这 么 商 单 吗 ? 非 也 ， 其 中 的 参数 actionName 指 xml 配 置 中 的 name 
属性 值 ， 它 与 从 HTTP 传 递 过 来 的 请 求 对 象 是 一 致 的 ， 根 据 HTTP 传 递 
过 来 的 actionName 在 xml 文 件 中 查找 对 应 的 节点 (Node) ,然后 就 可 以 获 
取 到 该 类 的 名 称 和 方法 ， 通 过 动态 代理 的 方式 执行 该 方法 ， 在 这 里 我 
们 使 用 到 了 代理 模式 。 


有 读者 可 能 听 说 过 反射 是 影响 性 能 的 ， 它 提供 解释 型 操作 。 是 这 


扩 ， 系 统 染 构 多 考虑 一 点 ， 提 升 的 性 能 远 比 这 个 多 。 


然后 我 们 再 来 看 拦截 器 ， 拦 截 器 和 过 滤器 的 区 别 就 是 : 拦截 器 可 
以 脱离 容器 〈J2EE 容 器 ) 运行 ， 而 过 滤器 不 行 。 拦 截 器 的 目的 是 对 数 
据 和 行为 进行 过 滤 ， 符 合 条 件 的 才 可 以 执行 Action， 或 者 是 在 Action 执 
行 完 毕 后 ， 调 用 拦截 器 进行 回收 处 理 。 我 们 定义 一 个 抽象 的 拦截 器 
如 代码 清单 37-15 所 示 。 


代码 清单 37-15 抽象 拦截 器 


public abstract class AbstractInterceptor { 

// 获 得 当前 的 值 栈 

private ValueStack valueStack = 
ValueStackHelper .getValueStack( ) ， 

// 拦 截 器 类 型 ， 前 置 、 后 置 、 环 绕 

private int type =0; 

// 当 前 的 值 栈 

protected ValueStack getValueStack(){ 

return valueStack; 


} 
// 拦 截 处 理 
public final void exec(){ 
// 根 据 type 不 同 ， 处 理 方式 也 不 同 


} 

// 拦 截 器 类 型 

protected abstract void setType(int type); 
// 子 类 实现 的 拦截 器 


protected abstract void intercept(); 


这 怎么 和 Struts 的 拦截 器 不 相同 呀 ! 是 的 ，Struts 的 拦截 器 的 拦截 方 
法 intercept 是 要 接收 一 个 ActionInvocation 对 象 ， 这 里 却 没 有 ， 我 们 主要 


尽 讲 解 模 式 ， 是 为 了 技术 实现 ， 而 类 似 Struts 的 MVC 和 框架 属于 工业 级 别 
的 应 用 框架 ， 考 虑 了 太 多 的 外 界 因 素 。 拦 截 砷 分 为 二 种 。 


e 刹 置 拦截 句 


在 Action 调 用 前 执行 ， 对 Action 需 要 的 场景 数据 进行 过 滤 或 重 构 。 
e 后 置 拦截 天 


在 Action 调 用 后 执行 ， 负 责 回 收场 景 ， 或 对 Action 的 后 续 事 务 进行 
处 理 。 


e 环绕 拦截 器 
在 Action 调 用 前 后 都 执行 。 


我 们 的 框架 在 这 里 使 用 了 一 个 模板 方法 模式 ， 开 发 者 继承 
AbstractInterceptor 后 ， 只 要 完成 两 个 职 贡 即 可 : 定义 拦截 类 型 
(setType) 和 实现 拦截 器 要 拦截 的 方法 (intercept) ， 不 用 考虑 它 到 底 
如 何 调用 ActionInvocation， 相 对 来 说 简单 又 实用 。 


有 拦截 吉 吏 肯定 有 拦截 郁 链 ， 多 个 拦截 大 组 合 在 一 起 束 成 了 拦截 
堪 链 ， 如 代码 清单 37-16 所 示 。 


代码 清单 37-16 拦截 器 链 


public class Interceptors implements 
Iterable<AbstractInterceptor> { 
// 根 据 拦 截 器 列表 建立 一 个 拦截 器 链 


public Interceptors(ArrayList<AbstractInterceptor> list){ 


} 

// 列 出 所 有 的 拦截 器 

public Iterator<AbstractInterceptor> iterator() { 
return null; 


// 拦 截 器 链 的 执行 方法 
public void intercept(){ 
// 委 托 拦截 器 执行 

} 


它 实 现 了 Tterable 接 口 ， 提 供 了 一 个 方便 角 历 拦截 器 的 方法 ， 这 是 
迭代 器 模式 。 同 时 ， 由 于 是 一 个 链 结构 ， 我 们 就 想到 了 责任 链 ， 这 里 
确实 也 是 一 个 贡 任 链 模 式 ， 只 是 核心 控制 右上 的 过 滤 链 是 Servlet 容 絮 目 
己 实现 的 ， 而 拦截 器 链 则 需要 我 们 目 己 编码 实现 。 代 码 不 复杂 ， 读 者 
可 以 参考 责任 链 章 节 。 


这 里 还 有 两 个 很 有 意思 的 方法 。 我 们 来 看 构造 钞 数 ， 它 通过 一 个 
容纳 有 拦截 器 的 动态 数组 生成 一 个 拦截 器 链 ， 它 是 一 个 自 激 行为 ， 在 
XML 文 件 中 配置 一 个 拦截 器 ， 其 中 包含 多 个 拦截 器 ， 我 们 的 构造 函数 
谍 是 这 样 的 用 途 ， 目 己 建 立 一 条 链 ， 而 不 是 父 类 或 者 高 层 模 块 。 再 看 
intercept 方 法 ， 链 中 每 个 斑点 都 是 一 个 拦截 得 ， 都 有 一 个 intercept 方 
法 ， 拦 截 硕 链 中 的 intercept 方 法 行为 是 委托 第 一 个 斑点 拦截 部 的 
intercept 方 法 ， 然 后 所 有 的 拦截 器 都 会 按照 顺序 执行 一 这， 这 一 点 和 我 
们 的 贡 任 链 模 式 是 不 同 的 ， 贡 任 链 模式 是 只 要 有 市 点 处 理 束 可 以 认为 
是 结束， 后 续 广 护 可 以 不 再 参与 处 理 。 


Struts 还 实现 了 方法 拦截 器 ， 只 要 继承 MethodFilterInterceptor 即 
可 ， 主 要 使 用 了 反射 技术 ， 有 兴趣 的 话 可 以 看 看 源 代码 。 注 意 我 们 这 
里 使 用 了 拦截 器 链 而 不 像 Struts 那 样 是 拦截 右 栈 ， 一 字 之 茎 ， 系 统 设计 
差别 可 就 大 了 。 


注意 ”拦截 器 是 会 影响 系统 性 能 的 ， 所 有 的 Action 在 执行 前 后 都 
会 个 拦 截 器 过 滤 一 壳 ， 即 使 不 符合 拦截 条 件 的 也 会 被 检查 一 裔 ， 所 以 
非 必要 情况 不 要 使 用 拦截 万 。 


由 于 在 XML 配 置 文档 中 有 太 多 的 拦截 器 链 ， 因 此 和 需要 有 一 个 工厂 
来 创建 它 ， 否 则 太 烦 开 。 如 代码 清单 37-17 所 示 。 


代码 清单 37-17 拦截 器 链 工 厂 


public class InterceptorFactory { 
public static ArrayList<Interceptors> createInterceptors(){ 
// 根 据 配置 文件 创建 出 所 有 的 拦截 器 链 


return null; 


) 


它 的 作用 是 根据 配置 文件 一 次 性 地 创建 出 所 有 的 拦截 器 ， 很 简单 
的 工厂 方法 模式 。 如 果 读 者 还 记得 我 们 刚刚 讲 的 配置 文件 更 新 问题 的 
话 ， 应 该 想到 这 里 也 应 该 有 一 个 观察 者 ， 配 置 文件 修改 了 ， 拦 截 郁 链 
当然 也 要 重建 了 ， 确 实 应 该 有 这 样 一 个 观察 者 ， 读 者 可 以 目 行 思考 如 
何 实 现 。 


37.1.3 值 栈 


值 栈 按 道理 说 应 该 很 商 单 ， 怠 是 把 HITTP 传 递 过 来 的 String 字 符 串 
压 到 堆栈 中 。 听 起 来 很 简单 ， 实 现 起 来 就 比较 有 难度 了 ， 它 要 完成 两 


= 接 
个 职责 。 


e 管理 堆栈 


不 仅仅 是 出 栈 、 入 栈 这 么 简单 ， 它 要 管理 栈 中 数据 ， 同 时 还 要 人 允 
许 前 置 拦截 器 对 栈 中 数据 进行 修改 ， 限 制 后 置 拦 堆 右 对 栈 的 修改 ， 还 
要 把 栈 中 数据 与 HTTPServletRequest 中 的 数据 建立 关联 。 


e 值 映 吊 


从 HTTP 传 递 过 来 的 数据 都 是 字符 串 结 构 ， 那 怎么 才能 转化 成 一 个 
业务 对 象 呢 ? 比如 在 页 面 上 有 一 个 登录 框 ， 输 入 用 户 名 (userName) 
和 密码 (password) 。 提 交 到 MVC 框 架 中 怎么 才能 转 为 一 个 User 对 象 
呢 ? 这 也 是 值 栈 要 完成 的 职责 。 


这 里 说 一 下 值 映射 ， 怎 么 实现 一 个 值 的 映射 ， 这 也 走 一 个 反 冉 操 
作 的 结果。 首 和 爷 是 HTTP 传递 过 来 的 参数 名 称 中 要 明确 映射 到 哪 一 个 对 
象 ， 例 如 使 用 点 号 (.) 区 分 ， 点 号 前 是 对 象 名 称 ， 点 号 后 是 属性 名 ， 如 
此 规定 后 就 可 以 轻松 地 处 理 了 。 由 于 使 用 的 模式 较 少 ， 这 里 就 不 再 芍 
述 。 谈 兰 各 有 兴趣 可 以 考虑 使 用 一 些 开 源 工 具 ， 比 如 dozer 等 。 


37.1.4 视图 管理 需 


视图 管理 器 的 功能 很 单一 ， 按 照 模型 指定 的 要 求 返 回 视 图 ， 在 这 
里 用 到 的 主要 模式 束 是 桥 染 模式 ， 如 条 大 家 做 过 多 语言 的 开发 融 非 党 
清楚 了 ， 比 如 一 个 外 部 网 站 ， 提 供 中 日 英 三 种 语言 版 本 ， 我 们 不 可 能 
每 个 语言 都 写 一 套 页 面 吧 。 一 般 是 定义 一 个 语言 俯 源 文件 ， 然 后 视图 
根据 不 同 的 语言 环境 加 载 不 同 的 语言 。 我 们 先 来 说 视图 ， 它 包含 三 部 


分 。 


e 前 仿 页 面 


比如 图 片 放 在 什么 地 方 ， 字 体 大 小 是 什么 样子 ， 有 菜单 应 该 放置 在 
什么 地 方 ， 这 部 分 工作 是 由 前 台 人 员 开 发 的 ， 不 涉及 业务 逻辑 和 业务 
数据 。 


e 动态 页 面 元 于 


它 指 的 是 在 一 个 固定 场景 下 不 发 生变 化 但 在 异 构 场 景 中 发 生变 化 
的 元 素 ， 其 中 语言 束 属 于 动态 页 面 元 素 ， 还 有 为 使 用 不 同 浏 览 絮 而 开 
发 的 代码 。 比 如 浏览 器 下 上、Firefox、Chrome 等 ， 虽 然 基本 上 都 是 符合 
HIML， 但 是 还 有 一 坚 细 世 差异， 特别 是 在 JavaScript 的 处 理 方 面 ， 稍 
不 注意 就 可 能 产生 灾难 。 


e 动态 数据 


由 模型 产生 的 数据 ， 它 对 视图 来 说 是 结构 固定 ， 并 可 反复 加 载 。 


在 这 三 部 分 中 ， 静 态 页 面 是 完全 静态 的 ， 动 态 页 面 元 素 是 稍微 有 
点 动感 ， 动 态 数据 完全 是 多 变 的 (数据 结构 不 发 生变 化 ， 否 则 页 面 无 
法 展现 ) 。 把 动态 数据 融入 到 静态 页 面 中 比较 容易 ， 已 经 在 配置 文件 
中 指定 要 把 模型 中 的 数据 放 到 哪个 页 面 中 ， 现 在 的 问题 是 怎么 把 动态 
页 面 元 素 融 入 到 静态 页 面 中 。 静 仿 页 面 有 很 多 ， 语 言 类 型 也 有 很 多 ， 
卜 么 融合 在 一 起 提供 给 浏览 絮 访 问 呢 ? 


桥梁 模式 可 以 解决 用 什么 笔 圆珠笔、 铅笔 和 画 什 么 图 形 〈 圆 
形 、 方 形 ) 的 问题 ， 我 们 直到 的 问题 与 此 场景 类 似 。 先 看 类 图 ， 如 图 
37-7 所 示 。 


+String getViewPath(String result) 


P| 


+AbsView(AbsLangData langData) +Map<String, String> getltems() 
中 


+AbsLangData getLangData() 
+void assemblel) 


cd We sg gr ~ 
中 文 语言 英文 语言 


图 37-7 视图 与 语言 类 图 


大 家 还 记得 Struts 是 怎么 配置 多 语言 的 文件 吗 ? 我 们 采用 类 似 的 结 
构 ， 如 代码 清单 37-18 所 示 。 
代码 清单 37-18 资源 配置 文件 


title= 标 题 
menu= 菜 单 


英文 配置 菜单 与 此 类 似 ， 它 的 结构 就 是 一 个 Map 类 型 ， 我 们 把 它 读 
入 到 Map 中 ， 抽 象 类 如 代码 清单 37-19 所 示 。 


代码 清单 37-19 抽象 语言 


public abstract class AbsLangData { 
// 获 得 所 有 的 动态 元 素 的 配置 项 
public abstract Map<String,String> getItems(); 


getItems 方 法 是 获得 一 种 语言 下 的 所 有 了 配置。 我 们 来 看 中 文 语言 
包 ， 如 代码 清单 37-20 所 示 。 


代码 清单 37-20 中 文 语言 


public class GBLangData extends AbsLangData { 
Q@Override 
public Map<String, String> getItems() { 


pi 


* Map 的 结构 为 : 
* key='title'，value=' 标 题 ' 
* key='menu'，value=' 菜 单 ' 


4 


return null; 


英文 语言 如 代码 清单 37-21 所 示 。 


代码 清单 37-21 英文 语言 


public class ENLangData extends AbsLangData { 
@Override 
public Map<String, String> getItems() { 
多 和 
* Map 结 构 为 : 
* key='title',value='title'; 


* key='menu'，Vvalue= 'menu' 
return null; 


视图 分 为 两 种 类 图 ， 一 种 是 需要 直接 替换 资源 文件 的 视图 ， 比 如 
JSP 文 件 ， 框 架 直 接 把 语言 包 中 的 资源 项 替换 挥 JSP 中 的 条 目 即 可 ， 把 
{title} 扳 换 为 “标题 "， 把 {menu} 翟 换 为 “ 末 单 ”， 礁 换 后 存在 框架 的 缓存 
目 永 中 ， 提 高 系统 的 访问 效率 。 另 一 种 视图 是 不 能 奉 换 的 ， 比 如 SWF 
文件 ， 它 的 资源 可 以 通过 类 似 HITP 传 递 参数 的 形式 传递 ， 重 写 一 个 
URL 即 可 。 我 们 首先 来 看 抽象 视图 ， 如 代码 清单 37-22 所 示 。 


代码 清单 37-22 抽象 视图 


public abstract class AbsView { 
private AbsLangData langData,; 
// 必 须 有 一 个 语言 文件 
public AbsView(AbsLangData _langData)t{ 
this.langData = _langData; 


} 

// 获 得 当前 的 语言 

public AbsLangData getLangData( ){ 
return langData; 


} 

/V 页 面 的 URL 路 径 

public String getURI(){ 
return null; 


// 组 装 一 个 页 面 
public abstract void assemble(); 


JSP 视 图 是 需要 替换 资源 项 ， 如 代码 清单 37-23 所 示 。 


代码 清单 37-23 JSP 视 图 


public class JspView extends AbsView { 

// 传 递 语言 配置 

public JspView(AbsLangData _langData)t{ 
super(_langData); 


Q@Override 
public void assemble() { 
Map<String,String> langMap = getLangData().getIitems(); 
for(String key:langMap.keySet())t{ 
phe 
* 直接 替换 文件 中 的 语言 条 目 


*/ 


SWF 文 件 钙 不 能 车 换 的 ， 采 用 重 写 URL 的 方式 ， 如 代码 清单 37-24 
所 未 


代码 清单 37-24 SWF 视图 


public class SwfView extends AbsView { 
public SwfView(AbsLangData _langData)t{ 
super(_langData); 


Q@Override 
public void assemble() { 
Map<String,String> langMap = 
getLangData( ) .getItems() ; 
for(String key:langMap.keySet())t{ 
/* 
* 组 装 一 个 HTTP 的 请 求 格式 : 
* http://abc.com/xxx.swf? 
key1=value&key2=value 
</ 
} 


ViewManager 是 一 个 视图 模块 的 入 口 ， 所 有 的 访问 都 是 通过 它 传递 
进来 的 ， 如 代码 清单 37-25 所 示 。 


代码 清单 37-25 视图 管理 


public class ViewManager { 

//Action 的 名 称 

private String actionName; 

// 当 前 的 值 栈 

private ValueStack valueStack = 
ValueStackHelper .getValueStack( ); 

// 接 收 一 个 ActionName 

public ViewManager(String _actionName){ 

this.actionName = _actionName; 


} 

// 根 据 模型 的 返回 结果 提供 视图 

public String getViewpath(String result)t{ 
// 根 据 值 栈 查 找到 需要 提供 的 语言 
AbsLangData langData = new GBLangData( ); 
// 根 据 action 和 result 查 找到 指定 的 视图 ， 并 加 载 语言 
AbsView view = new JspView(langData); 
// 返 回 视图 的 地 址 
return View.getURI( ) ; 


通过 桥梁 模式 我 们 把 不 同 的 语言 和 不 同类 型 的 视图 结合 起 来 ， 共 
同 提供 一 个 多 语言 的 应 用 系统 ， 即 使 以 后 增加 语言 也 非常 容易 扩展 。 


715 工具 类 


每 个 框架 或 项 目 都 有 大 量 的 工具 类 ，MVC 框 架 也 不 例外 。 先 来 看 
操作 XML 文件 的 工具 类 ， 不 可 能 自己 读 写 XML 文件 ， 我 们 使 用 DOM4j 


来 实现 ， 它 在 大 文件 的 处 理 上 性 能 很 有 优势 ， 而 且 比 较 人 简单 ， 架 构 也 
非常 优秀 。 


使 用 DOM4J 从 XML 文件 中 读 出 的 对 象 是 节点 (Node) 、 元 素 
(Element) 、 属 性 (Attribute) 等 ， 这 些 对 象 还 是 比较 容易 理解 的 ， 
但 是 不 能 保证 一 个 开发 组 的 人 对 这 些 都 了 解 ， 因 此 需要 把 它 转换 成 每 
个 开发 成 员 都 理解 的 对 象 ， 比 如 我 们 处 理 这 样 一 段 XML 代 码 ， 如 代码 

清单 37-26 所 示 。 


代码 清单 37-26 XML 文件 片段 


<action name="loginAction" class="{ 类 名 全 路 径 }" method="execute"> 
<result name="success">/index2.jsp</result> 
<result name="fail">/index.jsp</result> 

</action> 


使 用 DOM4J 查 找到 该 节点 是 一 个 Node 对 象 ， 如 果 要 取得 属性 ， 就 
需要 转换 为 一 个 元 素 (Elemenb 对 象 ， 这 不 是 每 个 开发 成 员 都 能 理解 
的 ， 于 是 给 架构 师 提出 的 问题 就 是 ， 如 何 把 一 个 DOM4J 对 象 转换 成 目 
己 设计 的 对 象 。 答 案 是 适配器 模式 ， 我 们 首先 定义 一 个 Action 世 点 类 ， 
如 代码 清单 37-27 所 示 。 


代码 清单 37-27 Action 节 点 类 


public abstract class ActionNode { 
//Action 的 名 称 


private String actionName; 


//Action 的 类 名 


private String actionClass; 


// 方 法 名 ， 默 认 是 execute 


private String methodName = "excuete"; 


// 视 图 路 径 


private String view; 


public String getActionName() { 


return actionName; 


public String getActionClass() { 


return actionClass; 


public String getMethodName() { 


return methodName; 


public abstract String getView(String Result); 


它 是 一 个 抽象 类 ， 其 中 的 getView 是 一 个 抽象 方法 ， 是 根据 执行 结 
果 查 找到 视图 路 人 笃 。 只 要 编写 一 个 适配器 就 可 以 把 Elemet 对 象 转 为 
Action 广 点 ， 如 代码 清单 37-28 所 示 。 


代码 清单 37-28 Action 节 点 


public class XmlActionNode extends ActionNode { 


// 需 要 转换 的 element 
private Element el; 


// 通 过 构造 丽 数 传递 


public XmlActionNode(Element _el)t{ 


this.el = _el; 


Q@Override 


public String getActionName(){ 


return getAttValue("name"); 


Q@Override 


public String getActionClass(){ 


return getAttValue("class"); 


Q@Override 


public String getMethodName(){ 


return getAttValue("method"); 


public String getView(String result){ 


ViewPathVisitor visitor = new ViewPathVisitor("success"); 


el.accept (visitor); 


return visitor.getViewpath(); 


// 获 得 指定 属性 值 


private String getAttValue(String attName ){ 
Attribute att = el.attribute(attName); 


return att ,getText() ， 


} 
} 


是 一 个 对 象 适 配器 ， 传 递 进来 一 个 Element 对 象 ， 把 它 转换 为 
ActionNode 对 象 ， 这 样 设计 以 后 ， 系 统 开 发 人 员 束 不 用 考虑 开源 工具 
对 系统 的 影响 ,屏蔽 了 工具 系统 的 影响 ， 这 是 一 个 典型 的 适 配 旭 模式 
必用 。 


不 知道 读者 是 否 注意 到 getView 方 法 ， 它 使 用 了 一 个 访问 者 模式 ， 
这 是 DOM4J 提 供 的 一 个 非常 优秀 的 API 接 口 ， 传 递 进去 一 个 访问 者 就 可 
以 饥 历 出 我 们 需要 的 对 象 。 我 们 来 看 目 己 定义 的 访问 者 ， 如 代码 清单 
37-29 所 示 。 


代码 清单 37-29 访问 者 


public class ViewPathVisitor extends VisitorSupport { 
// 获 得 指定 的 路 径 


private String ViewPath ; 


private String result 


// 传 递 模型 结果 


public ViewPathVisitor(String _result){ 


result = _result,; 


Q@override 

public void visit(Element el){ 
Attribute att = el.attribute("name"); 
if(att != null)t{ 


if(att.getName().equals("name") && att.getText().equals(result)) 
{ 


viewPath = el.getText(); 


} 


public String getViewPath(){ 


return viewPath,; 


I 


DOM4J 提 供 了 VisitorSupport 抽 象 接口 ， 可 以 接受 元 素 、 和 点 、 属 
性 等 访问 者 。 我 们 这 里 接受 了 一 个 元 素 访问 者 ， 对 所 有 的 元 素 过 滤 一 
遍 ， 然 后 找到 自己 需要 的 元 素 ， 非 常 强大 ! 


我 们 继续 分 析 ， 在 IoC 容 器 中 都 会 区 分 对 象 是 单 例 模式 还 是 多 例 模 
式 。 想 想 我 们 的 框 染 ， 每 个 HTTP 请 求 都 会 产生 一 个 线程 ， 如 果 我 们 的 
Action 初 始 化 的 时 候 是 单 例 模式 会 出 现 什么 情况 ? 当 并 发 足够 多 的 时 候 
就 会 产生 阻塞 ， 性 能 会 严重 下 降 ， 在 特殊 情况 下 还 会 产生 线程 不 安 
全 ， 这 时 就 需要 考虑 多 例 情况 。 那 多 例 是 如 何 处 理 呢 ?使 用 Clone 拉 
术 ， 首 先 在 系统 启动 时 初始 化 所 有 的 Action， 然 后 每 过 来 一 个 请 求 就 拷 
贝 一 个 Action， 减少 了 初始 化 对 象 的 性 能 消耗 。 典 型 的 原型 模式 ， 但 问 
题 也 同时 产生 了 ， 并 发 较 多 时 ， 束 可 能 会 产生 内 存 液 出 的 情况 ， 内 存 
不 够 用 了 ! 于 是 享 元 模式 就 可 以 上 场 了 ， 建 立 一 个 对 象 池 以 容纳 足够 多 
的 对 象 。 


37.2 最 佳 实践 


本 章 我 们 粗略 地 讲解 了 一 个 MVC 框 架 。 一 个 MVC 框 架 要 考虑 的 
外 界 环境 因素 太 多 了 ， 而 且 本 身 MVC 框 架 也 是 一 个 轻 量 型 的 ， 就 是 希 
望 我 们 编写 的 程序 在 没有 Struts、Spring MVC 等 框架 的 环境 中 不 需要 大 
规模 的 修改 照样 能 够 运行 ， 所 以 编写 一 个 框架 不 是 一 件 容易 的 事情 。 
幸运 的 是 我 们 以 学 习 模 式 为 主 ， 通 过 设计 MVC 框 架 来 了 解 设计 模式 。 
我 们 来 看 看 本 章 用 到 了 哪些 模式 。 


e 工厂 方法 模式 ， 通过 工厂 方法 模式 把 所 有 的 拦截 器 链 实 现 出 
来 ， 方 便 在 系统 初始 化 时 直接 处 理 。 


e 单 例 模式 : Action 的 默认 配置 都 是 单 例 模 式 ， 在 一 般 的 应 用 中 
单 例 已 经 足够 了 ， 在 复杂 情况 下 可 以 使 用 至 元 模式 提供 应 用 性 能 ， 减 
少 单 例 模式 的 性 能 隐患 。 


e 页 任 链 模式 ， 建 立 拦 截 器 链 以 及 过 滤 右 链 ， 实 现任 务 的 链条 化 
处 理 。 


e 太 代 俐 模式 ， 非 常 方 便 地 授 历 拦截 器 链 内 的 拦截 器 ， 而 不 用 再 
目 己 写 裔 历 拦截 絮 链 的 方法 。 


e 中 介 者 模式 ， 以 核心 控制 絮 为 核心 ， 其 他 同事 类 都 负责 为 核心 
控制 硕 “ 打 工 ”， 保 证 核心 控制 硕 瘦 小 、 稳 定 。 


e 观察 者 模式 : 配置 文件 修改 时 ， 不 用 重启 应 用 可 以 即刻 生效 ， 
提供 使 用 者 的 体验 。 


e 桥梁 模式 ， 使 不 同 的 视图 配合 不 同 的 语言 文件 ， 为 终端 用 户 展 
示 不 同 的 者 面 。 


e 策略 模式 ， 对 XML 文件 的 检查 可 以 使 用 两 种 不 同 的 策略 ， 而 且 
可 以 在 测试 机 和 开发 机 中 使 用 不 同 的 检查 策略 ， 方 便 系统 间 目 由 切 
换 。 


e 访问 者 模式 : 在 解析 XML 文件 时 ， 使 用 访问 者 非常 方便 地 访问 
到 需要 的 对 象 。 


e 适 配 右 模式 ， 把 一 个 开发 者 不 熟悉 的 对 象 转换 为 熟悉 的 对 象 ， 
避免 工具 或 框架 对 开发 者 的 影响 。 


e | ] 面 模式 Action 分 发 器 人 负责 所 有 的 Action 的 分 发 工作 ， 它 拓 供 
了 一 个 调用 Action 的 唯一 入 口 ， 避 人 免 外 部 模块 深入 到 模型 模块 内 部 。 


e 代理 模式 ， 大 量 使 用 动态 代理 ， 确 保 了 框 染 的 智能 化 。 


MVC 框 架 有 非常 成 熟 的 源码 ， 有 兴趣 的 读者 可 以 看 看 Struts 、 
Spring MVC 等 源码 ， 其 中 包含 了 非 彰 多 的 设计 模式 。 读 源码 是 提高 设 
计 技 能 和 开发 技能 的 一 个 重要 途径 ， 看 一 本 书 是 与 作者 进行 了 一 次 心 
灵 区 互 ， 看 一 份 源码 是 与 一 群 作者 进行 心灵 交互 ， 对 提高 目 己 的 技术 
修养 有 非 肖 大 的 帮助 。 


第 38 章 ” 痢 模 式 


设计 模式 已 经 诞生 多 年 , “23” 这 个 数字 也 在 逐渐 变 大 ， 这 十 好 事 
情 ， 表 明 我 们 软件 界 正 在 积累 、 汇 编 我 们 的 知识 和 经 验 。 一 个 模式 的 
提出 和 成 熟 需 要 一 段 时 间 ， 因 此 本 章 挑 选 了 5 个 大 家 时 常 使 用 ,但 又 经 
党 忽视 的 新 模 式 进行 讲解 ， 即 规格 模式 、 对 象 池 模式 、 雇 工 模式 、 
板 模式 、 至 对 象 模式 。 和 硕 望 这 5 个 新 模式 能 够 帮助 大 家 解决 更 多 的 实际 
开发 难题 。 


38.1 规格 模式 


38.1.1 规格 模式 的 实现 


不 知道 诸位 有 没有 使 用 C#3.5 做 过 开发 ， 它 有 一 个 非常 重要 的 新 特 
性 一 一 LINQ (Language INtegrated Query， 语 言 集成 查询 ) ， 它 提供 了 
类 似 于 SQL 语 法 的 壳 历 、 筛 选 等 功能 ， 能 完成 对 对 象 的 查询 ， 就 像 通 
过 SQL 语 句 查 询 数据 库 一 样 ， 例 如 这 样 的 一 个 程序 片段 : 

Dim DataList As String() = {"abc", "def", "ght"} 


Dim Result = From T As String In DataList Where T = "abc" 


这 人 句 话 的 意思 就 是 从 一 个 数组 中 查找 出 值 为 abc 的 元 素 ， 返 回 结果 
为 IEnumerable， 枚 举 嚣 类型。 注意 看 第 二 句 话 ， 它 使 用 了 类 似 SQL 的 
Select 语 法 结构 ，from、where 天 键 字 都 有 了 ， 而 且 还 支持 类 似 的 
Orderby、Groupby 功 能 ， 很 强大 ， 有 兴趣 的 读者 可 以 查阅 有 天资 料 。 
那 在 Java 世 界 中 是 否 也 存在 这 样 的 辅助 框架 呢 ? 有 ，JoSQL、Quaere 都 
可 以 提供 类 似 的 LINQ 语 言 ， 读 者 可 以 到 网 上 人 研究 一 下 JavaDoc， 同 样 非 
利 人 简单 ， 功 能 强大 。 


我 们 今天 要 讲 的 主题 与 LINQ 有 很 大 关系 ， 它 是 实现 LINQ 的 核心 。 
想 想 SQL 语句 中 什么 是 最 复杂 的 ， 是 where 后 面 的 查询 条 件 ， 看 看 目 己 
写 的 SQL 语句 基本 上 都 是 一 长 串 的 条 件 判 断 ， 中 间 一 堆 的 and、or、not 


逻辑 符 。 我 们 今天 的 任务 就 是 要 实现 条 件 语句 的 解析 ， 该 部 分 实现 
了 ， 基 本 上 LINQ 语 法 已 经 实现 了 一 大 半 。 


我 们 以 一 个 案例 来 讲解 该 技术 ， 在 内 存 中 有 10 个 User 对 象 ， 根 据 


不 同 的 条 件 查 找 出 用 户 ， 比 如 姓名 包含 某 个 字符 、 年 龄 小 于 多 少 尹 等 


条 件 ， 类 似 这 样 的 SQL: 


Select * From User where name like 


'% 


国庆 % 


查找 出 姓名 中 包含 “国庆 ”两 个 字 的 用 户 ， 这 在 关系 型 数据 库 中 很 
容易 实现 ， 但 是 在 对 象 群 中 怎么 实现 这 样 的 查询 呢 ? 好 ， 看 似 很 简 
单 ， 先 设计 一 个 用 户 类 ， 然 后 提供 一 个 用 户 查 找 工 具 类 ， 类 图 非常 容 


易 ， 如 图 38-1 所 示 。 


很 简单 的 类 图 ， 有 一 个 用 户 类 ， 同 时 提供 了 一 个 操作 用 户 的 辅助 
类 ， 我 们 先 来 看 User 类 ， 如 代码 清单 38-1 所 示 。 


User 


-String name 
-int age 


<<imterface>> 
IUserProvider 
E33 


+ArrayList findUserByNameEqual(String name) 
+ArrayList fndUserByAgeThan(int age) 


图 38-1 简单 用 户 查 询 类 图 


+User(Strng name, mt age) 
+getter/setter() 


代码 清单 38-1 用 户 类 


public class User { 

// 姓 名 

private String name; 

// 年 龄 

private int age; 

public User(String _name,int _age)t{ 
this.name = _name; 
this.age = _age; 


3 
public String getName() { 
return name; 


public void setName(String name) { 
this.name = name; 


public int getAge() { 
return age,; 


public void setAge(int age) { 
this.age = age; 


// 用 户 信息 打印 
Q@Override 


public String toString(){ 
return "用 户 名 : " + name+"Nt 年 龄 : " + age; 
} 


User 就 是 一 个 简单 BO 业务 对 象 ， 再 来 看 用 户 操作 接口 ， 它 定义 一 
个 用 户 操作 类 必须 具有 的 方法 ， 如 代码 清单 38-2 所 示 。 


代码 清单 38-2 用 户 操作 对 象 接口 


public interface IUserProvider { 
// 根 据 用 户 名 查找 用 户 
public ArrayList<User> findUserByNameEqual(String name); 
// 年 龄 大 于 指定 年 龄 的 用 
public ArrayList<User> findUserByAgeThan(int age); 


By 


在 这 里 只 定义 了 两 个 查询 实现 ， 分 别 古 名 字 相 同 的 用 户 和 年 龄 大 
于 指定 年 龄 的 用 户 ， 大 家 都 知道， 相似 的 查询 条 件 还 有 很 多 ， 比 如 名 
字 中 包含 指定 字符 、 年 龄 小 于 指定 年 龄 等 ， 我 们 仅 以 实现 这 两 个 碍 询 
作为 代表 ， 如 代码 清单 38-3 所 示 。 


代码 清单 38-3 用 户 操 作 类 


public class UserProvider implements IUserProvider { 

// 用 户 列表 

private ArrayList<User> userList; 

// 构 造 函 数 传 递 用 户 列表 

public UserProvider(ArrayList<User> userList)t{ 
this.userList = _userList,; 


} 
// 年 龄 大 于 指定 年 龄 的 用 户 
public ArrayList<User> findUserByAgeThan(int age) { 
ArrayList<User> result = new ArrayList<User>(); 
for(User u:userList)t{ 
if(u.getAge()>age){ // 符 合 条 件 的 用 户 
result.add(u); 


} 


return result,; 


} 
// 姓 名 等 于 指定 姓名 的 用 户 
public ArrayList<User> findUserByNameEqual(String name) { 
ArrayList<User> result = new ArrayList<User>(); 
for(User u:userList)t{ 
if(u.getName().equals(name)){// 符 合 条 件 
result.add(u); 
} 
} 


return result; 


通过 for 循 环 志 历 一 个 动态 数组 ， 判 断 用 户 是 否 符合 条 件 ， 将 符合 
条 件 的 用 尸 放置 到 为 外 一 个 数组 中 ， 比 较 人 简单 。 我 们 编写 场景 类 来 模 
拟 该 情景 ， 如 代码 清单 38-4 所 示 。 


代码 清单 38-4 场景 类 


public class Client { 
public static void main(String[] args) { 
// 首 先 初 始 化 一 批 用 
ArrayList<User> userList = new ArrayList<User>(); 
userList,add(new User(" 苏 大 ", 3)); 
UserList,add(new User(" 牛 二 ", 8)); 
userList,add(new User(" 张 三 ", 10)); 
userList.add(new User(" 李 四 ",15)); 
userList.add(new User(" 干 五 ", 18)); 
userList.add(new User(" 赵 六 ",20)); 

) 

) 

) 

) 


下 


UserList.add(new User(" 马 七 "，25 ) 
userList.add(new User(" 杨 八 ", 30) 
userList,add(new User(" 侯 九 ", 35) 
UserList,add(new User(" 布 十 ", 40) 
// 定 义 一 个 用 户 查 询 类 

IUserProvider userProvider = new 

UserProvider(userList); 

// 打 印 出 年 龄 大 于 20 岁 的 用 户 
System.out .println("=== 年 龄 大 于 20 岁 的 用 户 ===" ) ; 
for(User u:userProvider. findUserByAgeThan(20)){ 


System,out,printJln(uU) ; 


证 


运行 结果 如 下 所 示 : 


=- 年 龄 大 于 20 岁 的 用 户 === 


上 户 名 : 马 七 年龄， 25 


: 杨 八 年龄，30 


了 填 


名 
名 : 侯 九 年 龄 : 35 
名 


: 布 十 年 龄 : 40 


结 末 非 第 正确 ， 但 古 这 样 的 一 个 框 染 基 本 上 是 不 能 适应 业务 变化 
的 ， 为 什么 呢 ? 业务 变化 虽然 无 规则 ， 但 是 可 以 预测 ， 比 如 我 们 这 个 
查询 ,今天 要 查找 年 龄 大 于 20 罗 的 用 户 ， 明 天 要 查找 年 龄 小 于 30 罗 的 
用 户 ; 后天 要 查找 姓名 中 包 售 “国庆 "了 两 个 字 的 用 性; 想 想 看 
IUserProvider 接 口 是 不 是 要 一 直 修 改 下 去 ? 接口 是 小 约 ， 而 且 我 们 一 直 
提倡 面向 接口 编程 ， 但 是 在 这 里 接口 竟然 都 可 以 修改 ， 是 不 是 发 现 设 
计 有 很 大 问题 了 ! 


问题 发 现 了 ， 束 要 想 办 法 解决 。 再 回顾 一 下 编写 的 代码 ， 注 意 看 
findUserByAgeThan 和 findUserByNameEqual 两 个 方法 ， 两 者 的 代码 有 什 
么 不 同 呢 ? 除了 if 后 面 的 判断 条 件 不 同 外 ， 就 没有 不 同 的 地 方 了 ， 我 们 
一 直 在 说 封 效 变化 ， 这 两 段 程序 束 仪 仪 有 这 一 个 变化 点 ， 我 们 是 不 是 


可 以 把 它 封 狐 起 来 呢 ? 完全 可 以 ， 把 它们 两 者 的 共同 点 抽取 出 来 ， 先 
修改 一 下 接口 ， 如 代码 清单 38-5 所 示 。 


代码 清单 38-5 修正 后 的 接口 


public interface IUserProvider { 
// 和 根据 条 件 查 找 用 


public ArrayList<User> findUser(boolean condition); 


ly 


这 个 接口 的 设计 想法 非常 好 ， 但 是 参数 condition 很 难 实现 ， 看 看 
findUserByAgeThan、findUserByNameEqual 这 两 个 方法 ， 怎 么 才能 把 两 
者 的 不 同 点 设置 成 一 个 布尔 型 呢 ? 如 有 果 需 要 在 IUserProvider 对 象 外 判断 
后 传递 进来 ， 那 我 们 的 封装 就 没有 任何 意义 了 一 一 目前 为 止 ， 这 个 方 


案 有 问题 了 。 


继续 考虑 ， 既 然 不 能 在 封装 外 运算 ， 那 就 把 整个 条 件 都 进行 封 

， 由 IUserProvider 目 己 实 现 运算 。 好 方法 ! 那 我 们 就 设计 一 个 这 样 的 
类 ， 我 们 叫 它 规格 类 ， 什 么 意思 呢 ? 它 是 对 一 批 对 象 的 说 明 性 描述 ， 
它 依照 基准 判断 候选 对 象 是 否 满足 条 件 。 


法 


思考 后 ， 我 们 设计 出 类 图 ， 如 图 38-2 所 示 。 


<<interface>> <<interface>> 
IUserProvider IUserSpecification 


+ArrayList findUser(IUserSpecification userSpec) +boolean isSatisfiedBy(User user) 


UserByNameEqual UserByAgeThan 
一 一 一 一 一 一 | | 
| 


年 版 天 于 基准 规格 人 
图 38-2 加 入 规格 后 的 设计 类 图 


在 该 类 图 中 建立 了 一 个 规格 书 接口 ， 它 的 作用 就 是 定制 各 种 各 样 
的 规格 ， 比 如 名 字 相 等 的 规格 UserByNameEqual、 年 龄 大 于 基准 年 龄 的 
规格 UserByAgeThan 等 ， 然 后 在 用 户 操 作 类 中 采用 该 规格 进行 判断 。 
User 类 没有 任何 改变 ， 如 代码 清单 38-1 所 示 ， 不 再 资 述 。 


规格 书 接口 古 对 全 体 规格 书 的 声明 定义 ， 如 代码 清单 38-6 所 示 。 


代码 清单 38-6 规格 书 接口 


public interface IUserSpecification { 
// 候 选 者 是 否 满足 要 求 
public boolean isSatisfiedBy(User USser ) 


规格 书 接口 只 定义 一 个 方法 ， 判 断 候选 用 户 坪 否 满足 条 件 。 再 来 
看 姓名 相同 的 规格 书 ， 它 实现 了 规格 书 接口 ， 如 代码 清单 38-7 所 示 。 


代码 清单 38-7 姓名 相同 的 规格 书 


public class UserByNameEqual implements IUserSpecification { 

// 基 准 姓 名 

private String name; 

// 构 造 画 数 传递 基准 姓名 

public UserByNameEqual(String _name)t{ 
this.name = _name; 


} 

// 检 验 用 户 是 否 满足 条 件 

public boolean isSatisfiedBy(User user) { 
return user.getName().equals(name); 

} 


代码 很 位 单 ， 通 过 构造 钞 数 传递 进来 基准 用 户 名 ， 然 后 判断 候 克 
用 户 是 否 匹 配 。 大 于 基准 年 龄 的 规格 书 与 此 类 似 ， 如 代码 请 单 38-8 所 


修 ° 


代码 清单 38-8 大 于 基准 年 龄 的 规格 书 


public class UserByAgeThan implements IUserSpecification { 
// 基 ? 年 龄 
private int age; 
// 构 造 函 数 传递 基准 年 龄 
public UserByAgeThan(int _age)t{ 
this.age = _age; 


} 

// 检 验 用 户 是 否 满 足 条 件 

public boolean isSatisfiedBy(User user) { 
return user.getAge() > age; 

} 


规格 书 都 已 经 定义 完毕 ， 我 们 再 来 看 用 户 操 作 类 ， 先 看 用 户 操作 
的 接口 ， 如 代码 清单 38-9 所 示 。 


代码 清单 38-9 用 户 操 作 接 口 


public interface IUserProvider { 
// 根 据 条 件 查找 用 
public ArrayList<User> findUser(IUserSpecification 
userSpec); 


ly 


只 有 一 个 方法 一 一 根据 指定 的 规格 书 查 找 用 户 。 再 来 看 其 实现 
类 ， 如 代码 清单 38-10 所 示 。 


代码 清单 38-10 用 户 操 作 
public class UserProvider implements IUserProvider { 
// 用 户 列 表 
private ArrayList<User> userList; 
// 传 递 用 户 列表 
public UserProvider(ArrayList<User> _userList)t{ 
this.userList = _userList,; 


} 
// 根 据 指定 的 规格 书 查 找 用 户 
public ArrayList<User> findUser(IUserSpecification 
userSpec) { 
ArrayList<User> result = new ArrayList<User>(); 
for(User u:userList)t{ 
if(userSpec.isSatisfiedBy(u)){// 符 合 指 定 规格 
result.add(u); 


} 
和 


return result,; 


程序 改动 很 小 ， 仅 仅 在 if 济 断 语句 中 根据 规格 书 进行 判断 ， 我 们 持 
续 地 扩展 规格 书 ， 有 多 少 查 询 分 类 就 可 以 扩展 出 多 少 个 实现 类 ， 而 
IUserProvider 则 不 需要 任何 改动 ， 它 的 一 个 方法 就 覆盖 了 我 们 刚刚 提出 


的 N 多 查询 路 径 。 我 们 设计 一 个 场景 来 看 看 效果 如 何 ， 如 代码 清单 38- 
11 所 示 。 


代码 清单 38-11 场景 类 


public class Client { 
public static void main(String[] args) { 
// 首 先 初始 化 一 批 用 
ArrayList<User> userList = new ArrayList<User>(); 
userList,add(new User(" 苏 大 ", 3)); 


ly 


userList. 
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20) ) 


User(" 马 七 "，25) ) ; 
User(" 杨 八 ", 30) ) ; 
User(" 候 九 ",，35) ) ; 
User(" 布 十 ", 40)); 


// 定 义 一 个 用 户 查 询 类 

IUserProvider userProvider = new 
UserProvider(userList); 

// 打 印 出 年 龄 大 于 20 岁 的 用 户 

System.out .println("=== 年 龄 大 于 20 岁 的 用 

// 定 义 一 个 规格 书 

IUserSpecification userSpec = 
UserByAgeThan(20); 

for(User u:userProvider.findUser(userSpec))t 

System.out.println(u); 
} 


户 ===" ) > 


New 


在 场景 类 中 定义 了 一 个 规格 书 ， 然 后 把 规格 书 提交 给 UserProvider 
就 可 以 查找 到 自己 需要 的 用 户 了 ， 运 行 结 果 相 同 ， 不 再 长 述 。 


大 家 想 想 看 ， 如 果 现在 需求 变更 了 ， 比 如 需要 一 个 年 龄 小 于 基准 
年 龄 的 用 户 ， 该 有 怎 么 修改 ? 增加 一 个 小 于 基准 年 龄 的 规格 书 ， 实 现 


IUserSpecification 接 口 ， 然 后 在 新 的 业务 中 调用 即 可 ， 别 的 什么 都 不 需 
要 修改 。 再 比如 需要 一 个 类 似 SQL 中 like 语 句 的 处 理 逻 辑 ， 这 个 也 不 
难 ， 如 代码 清单 38-12 所 示 。 


代码 清单 38-12 Like 规 格 书 


public class UserByNameLike implements IUserSpecification { 
//1ike 的 标记 
private final static String LIKE_ FLAG = "%"; 
// 基 准 的 1ike 字 符 串 
private String likeStr; 
// 构 造 函 数 传递 基准 姓名 
public UserByNameLike(String _likeStr)t{ 
this.1likestr = _likeSstr,; 


} 
// 检 验 用 户 是 否 满足 条 件 
public boolean isSatisfiedBy(User user) { 
boolean result = false; 
String name = user .getName( ); 
// 蔡 换 掉 % 后 的 干净 字符 串 
String str = likeStr.replace("%",""); 
// 是 以 名 字 开 头 ， 如 ' 国 庆 %' 
if(1ikeSstr.endswith(LIKE_FLAG) && 
!1ikeStr.startswith(LIKE_ FLAG)){ 
result = name.startswith(str); 
}else if(likeStr.startswith(LIKE_ FLAG) && 
11ikeStr .endswith(LIKE_FLAG)){ // 类 似 '% 国 庆 ' 
result = name.endswith(str); 
}elsef{ 
result = name.contains(str); // 类 似 于 '% 国 庆 %' 
} 


return result; 


同时 ， 场 景 类 也 要 适当 地 改动 ， 毕 竟 业 务 已 经 发 生 了 变化 ， 高 层 
模块 要 适应 这 种 变化 ， 如 代码 清单 38-13 所 示 。 


代码 清单 38-13 场景 


public class Client { 
public static void main(String[] args) { 

// 首 先 初始 化 一 批 用 
ArrayList<User> userList = new ArrayList<User>(); 
userList,add(new User(" 苏 国庆 ", 23)); 
userList,add(new User ("国庆 牛 ", 82)); 
userList,add(new User(" 张 国庆 三 ", 10)); 
userList.add(new User(" 李 四",10)); 
// 定 义 一 个 用 户 查 询 类 
IUserProvider userProvider = new 

UserProvider(userList),; 
// 打 印 出 名 字 包 含 "国庆 "的 人 员 
System,.out.println("=== 名 字 包 含 国庆 的 人 员 ===" );} 
// 定 义 一 个 规格 书 
IUserSpecification userSpec = new UserByNameLike("% 


ly 


国庆 %" ) ;， 
for(User u:userProvider.findUser(userSpec))t{ 
System.out.println(u); 
} 
} 
} 
运行 结果 如 下 所 示 : 
=== 名 字 包 含 国 庆 的 人 员 === 


j 户 名 :办 国庆 ”年龄 ，23 


] 户 名 : 国庆 和 牛 年 龄 : 82 


户 名 : 张 国 庆 三 ”年 龄 : 10 


到 目前 为 上 ， 我 们 已 经 设计 了 一 个 可 扩展 的 对 象 查 询 平 台 ， 但 是 
我 们 还 有 遗留 问题 示人 解决， 看 看 SQL 语 句 ， 为 什么 where 后 面 会 很 长 ? 
征 因 为 有 AND、OR、NOT 这 些 逻 辑 操作 符 的 存在 ， 它 们 可 以 串联 起 多 
个 判断 语句 ， 然 后 整体 反馈 出 一 个 结果 来 。 想 想 看 ， 我 们 上 面 的 平台 
能 文 持 这 种 逻辑 操作 符 吗 ? 不 能 ， 你 要 说 能 ， 那 也 说 得 通 ， 需 要 两 次 


过 滤 才 能 实现 ， 比 如 要 找 名 字 包 侣 “国庆 ”并且 年 龄 大 于 25 多 的 用 户 ， 
代码 该 怎么 修改 ? 如 代码 清单 38-14 所 示 。 


代码 清单 38-14 复合 查询 


public class Client { 
public static void main(String[] args) { 
// 定 义 一 个 规格 书 
IUserSpecification UserSpec1 = new 
UserByNameLike("% 国 庆 %" )，; 
IUserSpecification userSpec2 = new 
UserByAgeThan(20); 
userList = userProvider.findUser(userSpeci1); 
for(User u:userProvider.findUser(userSpec2))t{ 
System.out.println(u); 


能 够 实现 ， 但 是 思考 一 下 程序 逻辑 ， 它 采用 了 两 次 过 滤 ， 也 就 是 
两 次 循环 ， 如 果 对 象 数量 少 还 好 说 ， 如 果 对 象 数量 巨大 ， 这 个 效率 就 
太 低 了 ， 这 是 其 一 ， 其 二 ， 组 合 方式 非常 多 ， 比 如 “与 ”`“ 或 ”`\“ 非 ?可 
以 目 由 组 合 ， 姓 名 中 包 舍 “国庆 ”但 年 龄 小 于 25 的 用 户 ， 姓 名 中 不 包 
国庆 但 年 龄 大 于 25 多 的 用 户 等 ， 我 们 还 能 如 此 设计 吗 ? 太 多 的 组 合 方 
式 ， 产 生 组 合 爆炸 ， 这 种 设计 束 不 有 区 了 ， 应 该 有 更 优秀 的 方案 。 


我 们 换个 方式 思考 该 问题 ， 不 管 和 证 AND 或 者 OR 或 者 NOT 操 作 ， 蕊 
们 的 返回 结果 都 还 是 一 个 规格 书 ， 只 是 逻辑 更 复 沫 了 而 已 ， 这 3 个 操作 
符 只 是 提供 了 对 原 有 规格 书 的 复合 作用 ， 换 句 话 说 ， 规 格 书 对 象 之 间 


可 以 进行 与 或 非 操 作 ， 损 作 的 结 采 不 变 ， 分 析 到 这 里 ， 我 们 惑 可 以 开 
台 修 改 接 口 了 ， 如 代码 清单 38-15 所 示 。 


代码 清单 38-15 市 与 或 非 的 规格 书 接口 


public interface IUserSpecification { 
// 候 选 者 是 否 满足 要 求 
public boolean isSatisfiedBy(User USser ) 
//and 操 作 
public IUserSpecification and(IUserSpecification spec); 
//or 操 作 
public IUserSpecification or(IUserSpecification spec); 
//not 操 作 
public IUserSpecification not(); 


在 规格 书 接口 中 增加 了 与 或 非 的 操作 ， 接 口 修改 了 ， 实 现 类 当然 
也 要 修改 。 先 全 面 思 考 一 下 业务 ， 与 或 非 是 不 可 扩展 的 操作 ， 规 格 书 
(也 就 是 规格 对 象 ) 之 间 的 操作 只 有 这 三 种 方法 ， 是 不 需要 扩展 也 不 
用 预 留 扩展 空间 的 。 如 此 ， 我 们 惑 可 以 把 与 或 非 的 实现 放 到 基 类 中 ，， 
那 现 在 的 问题 变 成 了 怎么 在 基 类 中 实现 与 或 非 。 注 意 看 它们 的 返回 值 
都 需要 返回 规格 书 类 型 ， 很 明显 ， 我 们 在 这 里 要 用 到 递归 调用 了 。 可 
以 这 样 理解 ， 基 类 需要 子 类 提供 业务 逻辑 文 持 ， 因 为 基 类 是 一 个 抽象 
类 ， 不 能 实例 化 后 返回 ， 我 们 把 简单 类 疼 画 出 来 ， 如 网 38-3 所 示 。 
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图 38-3 与 规格 的 示意 


基 类 对 子 类 产生 了 依赖 ， 然 后 进行 递归 计算 ， 大 家 一 定 会 发 出 这 
样 的 疑 站 ， 父 类 怎么 可 能 依赖 子 类 ， 这 还 古 面 同 接 口 编程 鸣 ? 想 想 

看 ， 我 们 提出 面向 接口 编程 的 目的 是 什么 ? 是 为 了 适应 变化 ， 拥 抱 变 
化 ， 对 于 不 可 能 发 生变 化 的 部 分 为 什么 不 能 固化 呢 ? 与 或 非 操 作 符号 


还 会 增加 修改 吗 ? 规格 书 对 象 之 间 的 操作 还 有 其 他 吗 ? 思考 清楚 这 些 


问题 后 ， 答 案 丈 迎刃而解 了 。 


注意 ” 父 类 依赖 子 类 的 情景 只 有 在 非常 明确 不 会 发 生变 化 的 场景 
中 存在 ， 它 不 具备 扩展 性 ， 古 一 种 固化 而 不 可 变化 的 结构 。 


分 析 完 毕 ， 我 们 设计 出 详细 的 类 图 ， 如 图 38-4 所 示 。 


可 能 大 家 有 很 多 的 疑问 ， 我 们 先 来 分 析 代 码 ， 代 码 分 析 完 毕 估 计 
能 解决 你 大 部 分 的 疑问 。 规 格 书 接口 如 代码 清单 38-15 所 示 ， 不 再 殉 
述 。 我 们 来 看 组 合 规格 书 (CompositeSpecification) ， 它 是 一 个 抽象 
类 ， 实 现 了 与 或 非 的 操作 ， 如 代码 请 单 38-16 所 示 。 


代码 清单 38-16 组 合 规格 书 


public abstract class CompositeSpecification implements 
IUserSpecification { 
// 是 否 满足 条 件 由 实现 类 实现 
public abstract boolean isSatisfiedBy(User user); 
//and 操 作 
public IUserSpecification and(IUserSpecification spec) { 
return new AndSpecification(this, spec); 


} 
//not 操 作 
public IUserSpecification not() { 
return new NotSpecification(this); 


} 

//or 操 作 

public IUserSpecification or(IUserSpecification spec) { 
return new OrSpecification(this, spec); 

} 


<<mterface>> 


本 lIUserSpecification 
规格 书 接口 一 
+boolean isSatisfiedBy(User user) 
+IUserSpecification and(IUserSpecification spec) 
+HIUserSpecification or(IUserSpecification spec) 
+IUserSpecification not() 


年 龄 大 于 基准 年 龄 
UserByAgeThan i 
0 CompositeSpecification 
==== == = = = = = 二 = 
+IUserSpecification and(IUserSpecification spec) 
a bid i be +IUserSpecification not() 
| +IUserSpecification or(IUserSpecitication spec) 


姓名 相同 ; ; ; 
AndSpecification| | OrSpecification| | NotSpecification 
| 
ES 


图 38-4 完整 规格 书 类 图 


候选 对 象 是 否 满足 条 件 是 由 isSatisfiedBy 方 法 决定 的 ， 它 代表 的 是 
一 个 判断 逻辑 ， 由 各 个 实现 类 实现 。 三 个 与 或 非 操 作 在 抽象 类 中 实 
现 ， 它 是 通过 直接 new 了 一 个 子 类 ， 如 此 设计 非常 符合 单一 职责 原则 ， 
每 个 子 类 都 有 一 个 独立 的 职责 ， 要 么 完成 “与 ”操作 ， 要 么 完成 或" 操 
作 ， 要 么 完成 “ 非 ” 操 作 。 我 们 先 来 看 “与 ”操作 规格 书 ， 如 代码 清单 38- 
17 所 示 。 


代码 清单 38-17 与 规格 书 


public class AndSpecification extends CompositeSpecification { 
// 传 递 两 个 规格 书 进 行 and 操 作 
private IUserSpecification left; 
private IUserSpecification right; 
public AndSpecification(IUserSpecification 
_left,IUserSpecification _right){ 
this.Jleft = _left; 
this.right = _right; 


} 
// 进 行 and 运 算 
Q@Override 
public boolean isSatisfiedBy(User user) { 
return left.isSatisfiedBy(user) && 
right.isSatisfiedBy(user); 


} 
} 


通过 构造 函数 传递 过 来 两 个 需要 操作 的 规格 书 ， 然 后 通过 
isSatisfiedBy 方 法 返回 两 者 and 操 作 的 结 采 。 或 规格 书 和 非 规 格 书 与 此 类 
似 ， 分别 如 代码 清单 38-18、 代 码 清单 38-19 所 示 。 


代码 清单 38-18 或 规格 书 


public class OrSpecification extends CompositeSpecification { 
// 左 右 两 个 规格 书 
private IUserSpecification left; 
private IUserSpecification right; 
public OrSpecification(IUserSpecification 
_left,IUserSpecification _right){ 
this, left = _left; 
this.right = _right; 


} 
//or 运 算 
Q@Override 
public boolean isSatisfiedBy(User user) { 
return left.isSatisfiedBy(user) || 
right.isSatisfiedBy(user); 


} 
} 


代码 清单 38-19 非 规 格 书 


public class NotSpecification extends CompositeSpecification { 
// 传 递 一 个 规格 书 
private IUserSpecification spec; 
public NotSpecification(IUserSpecification _spec)t 
this.spec = _spec; 


} 

//not 操 作 

Q@Override 

public boolean isSatisfiedBy(User user) { 
return !spec.isSatisfiedBy(user ); 

} 


这 三 个 规格 书 都 是 不 发 生变 化 的 ， 只 要 使 用 该 框架 ， 三 个 规格 书 
都 要 实现 的 ， 而 且 代 码 基 本 上 是 雷同 的 ， 所 以 才 有 了 父 类 依赖 子 类 的 
设计 ， 否 则 是 严禁 出 现 父 类 依赖 子 类 的 情况 的 。 大 家 再 仔细 看 看 这 二 
个 规格 书 和 组 合 规格 书 ， 代 码 很 简单 ， 但 也 很 巧妙 ， 它 跳出 了 我 们 面 
向 对 象 设计 的 思维 ， 不 变 部 分 使 用 一 种 固化 方式 实现 。 


姓名 相同 、 年 龄 大 于 基准 年 龄 、Like 格 式 等 规格 书 都 有 少许 改变 ， 
把 实现 接口 变 为 继承 基 类 ， 我 们 以 名 字 相 等 规格 书 为 例 ， 如 代码 清单 
38-20 所 示 。 


代码 清单 38-20 姓名 相同 规格 书 


public class UserByNameEqual extends CompositeSpecification { 

// 基 准 姓 名 

private String name; 

// 构 造 函 数 传 递 基 准 姓名 

public UserByNameEqual(String _name ){ 
this.name = _name; 


} 

// 检 验 用 户 是 否 满足 条 件 

public boolean isSatisfiedBy(User user) { 
return user.getName().equals(name); 


se 


仅仅 修改 了 黑体 部 分 ， 其 他 没有 任何 改变 。 另 外 两 个 规格 书 修改 
相同 ， 不 再 警 述 。 其 他 的 User 及 UserProvider 没 有 任何 改动 ， 不 再 歼 


了 述 。 


我 们 修改 一 下 场景 类 ， 如 代码 清单 38-21 所 示 。 


代码 清单 38-21 场景 


public class Client { 
public static void main(String[] args) { 

// 首 先 初始 化 一 批 用 
ArrayList<User> userList = new ArrayList<User>(); 
userList,add(new User(" 苏 国庆 ", 23)); 
userList,add(new User ("国庆 牛 ", 82)); 
userList,add(new User(" 张 国庆 三 ", 10)); 
userList.add(new User(" 李 四 ",10)); 
// 定 义 一 个 用 户 查 询 类 
IUserProvider userProvider = new 

UserProvider(userList); 
// 打 印 出 名 字 包 含 "国庆 "的 人 员 
System,out,.println("=== 名 字 包 含 国庆 的 人 员 ===" );} 
// 定 义 一 个 规格 书 
IUserSpecification spec = new UserByAgeThan(25); 
IUserSpecification spec2 = new UserByNameLike("% 国 


ly 


庆 %"); 
for(User u:userProvider.findUser(spec.and(spec2)))t{ 
System.out.println(u); 
} 


证 


在 场景 类 中 我 们 建立 了 两 个 规格 书 ， 一 个 是 年 龄 大 于 25 的 用 户 ， 
另 一 个 是 名 字 中 包 侣 “国庆 ”两 个 字 的 用 户 ， 这 两 个 规格 书 之 间 的 天 系 
是 “与 ?关系 ， 运 行 结 果 如 下 : 


=== 名 字 包 含 国庆 的 人 员 === 


j 户 名 :国庆 牛 ”年龄 ，82 


到 此 为 止 我 们 的 LINQ 已 经 完成 了 很 大 一 部 分 了 ，SQL 语 句 中 的 
where 后 面部 分 已 经 可 以 解析 了 ， 完 全 可 以 再 增加 年 龄 相等 的 规格 书 、 
姓名 字数 规格 书 等 ， 你 在 SQL 中 使 用 过 的 条 件 在 这 里 都 能 实现 了 。 功 
臣 还 是 依赖 于 三 个 与 或 非 规 格 书 ， 有 了 它们 三 个 栋梁 才能 组 合 出 一 个 
精彩 的 条 件 查 询 世 界 。 


38.1.2 最 佳 实践 


我 们 在 例子 中 多 次 提 到 规格 两 个 字 ， 该 实现 模式 区 叫做 规格 模式 
(Specification Pattern) ， 它 不 属于 23 个 设计 模式 ， 它 是 其 中 一 个 模式 
的 扩展 ， 是 哪个 模式 呢 ? 


我 们 用 全 局 的 观点 思考 一 下 ， 基 类 代表 的 是 所 有 的 规格 书 ， 它 的 
目的 是 摘 述 一 个 完整 的 、 可 组 合 的 规格 书 ， 它 代表 的 是 一 个 整体 ， 其 
下 的 And 规 格 书 、Or 规 格 书 、Not 规 格 书 、 年 龄 大 于 基准 年 龄 规格 书 等 
都 古 一 个 真实 的 实现 ， 也 就 是 一 个 局 部 ， 现 在 我 们 义 回 到 了 整体 和 部 
分 的 关系 了 ， 那 这 是 什么 模式 ? 对 ， 组 合 模式 ， 它 是 组 合 模 式 的 一 种 
特殊 应 用 ， 我 们 来 看 它 的 通用 类 图 ， 如 图 38-5 所 示 。 


<<interface>> 
ISpecification 
| 


+boolean isSatisfiedBy(Object candidate) 


+IUserSpecification and(IUserSpecification spec) 
+IUserSpecification or(IUserSpecification spec) 
+IUserSpecification not() 


Composite Specification 


| 
+IUserSpecification and(IUserSpecification spec) (| 
+IUserSpecification or(IUserSpecification spec) 

+IUSserSpecification not() 


AndSpecification| |OrSpecification| | NotSpecification 


BizSpecification 


图 38-5 规格 模式 通用 类 图 


为 什么 在 通用 类 图 中 把 方法 名 称 都 定义 出 来 呢 ? 是 因为 只 要 使 用 
规格 模式 ， 方 法 名 称 都 是 这 四 个 ， 它 是 把 组 合 模式 更 加 具体 化 了 ， 放 
在 一 个 更 狭小 的 应 用 空间 中 。 我 们 再 仔细 看 看 ， 还 能 不 能 找到 其 他 模 
式 的 映 影 ? 对 ， 宋 略 模 式 ， 每 个 规格 书 都 旦 一 个 策略 ， 它 完成 了 一 系 
列 人 逻辑 的 封 汉 ， 用 年 龄 相等 的 规格 书 蕉 换 年 龄 大 于 指定 年 龄 的 规格 书 
上 层 逻 辑 有 什么 改变 吗 ? 不 需要 任何 改变 ! 


规格 模式 非常 重要 ， 它 巧妙 地 实现 了 对 象 筷 选 功能 。 我 们 来 看 其 
通用 源码 ， 首 先 看 抽象 规格 书 ， 如 代码 清单 38-22 所 示 。 


代码 清单 38-22 抽象 规格 书 


public interface ISpecification { 
// 候 选 者 是 否 满足 要 求 
public boolean isSatisfiedBy(Object candidate ) ; 


//and 操 作 
public ISpecification and(ISpecification spec); 
//or 操 作 
public ISpecification or(ISpecification spec); 
//not 操 作 


public ISpecification not(); 


组 合 规格 书 实现 与 或 非 的 算法 ， 如 代码 清单 38-23 所 示 。 


代码 清单 38-23 组 合 规 格 书 


public abstract class CompositeSpecification implements 
Topecif Leat Lon { 
// 是 否 满足 条 件 由 实现 类 实现 
public abstract boolean isSatisfiedBy(Object candidate); 
//and 操 作 
public ISpecification and(ISpecification spec) { 
return new AndSpecification(this, spec); 


} 
//not 操 作 
public ISpecification not() { 
return new NotSpecification(this); 


} 

//or 操 作 

public ISpecification or(ISpecification spec) { 
return new OrSpecification(this, spec); 

} 


与 或 非 规 格 书 代码 分 别 如 代码 清单 38-24 至 代码 清 蛙 38-26 所 示 。 


代码 清单 38-24 与 规格 书 


public class AndSpecification extends CompositeSpecification { 


// 传 递 两 个 规格 书 进行 and 操 作 


private ISpecification Left 
private ISpecification right; 
public AndSpecification(ISpecification _left,ISpecification 
_right)t 
this.left = _left; 
this.right = _right,; 


} 
// 进 行 and 运 算 
@Override 
public boolean isSatisfiedBy(Object candidate) { 
return left.isSatisfiedBy(candidate) && 
right.isSatisfiedBy(candidate); 


} 
代码 清单 38-25 或 规格 书 


public class OrSpecification extends CompositeSpecification { 
// 左 右 两 个 规格 书 
private ISpecification left; 
private ISpecification right; 
public OrSpecification(ISpecification _left,ISpecification 
_right)t{ 


this, left = _left; 
this.right = _right,; 


} 
//or 运 算 
Q@Override 
public boolean isSatisfiedBy(Object candidate) { 
return left.isSatisfiedBy(candidate) || 
right.isSatisfiedBy(candidate); 


} 
} 
代码 清单 38-26 非 规 格 书 


public class NotSpecification extends CompositeSpecification { 
// 传 递 一 个 规格 书 
private ISpecification spec; 
public NotSpecification(ISpecification _spec)t{ 
this.spec = _spec; 


} 

//not 操 作 

@Override 

public boolean isSatisfiedBy(Object candidate) { 


return !spec.isSatisfiedBy(candidate); 


以 上 一 个 接口 、 一 个 抽象 类 、3 个 实现 类 只 要 在 适用 规格 模式 的 地 
方 都 完全 相同 ， 不 用 做 任何 的 修改 ， 大 家 闭 着 眼 照抄 就 成 ， 要 修改 的 
征 下 面 的 规格 书 


3 


代码 清单 38-27 业务 规格 书 


public class BizSpecification extends CompositeSpecification { 
// 基 准 对 象 
private Object obj ; 
public BizSpecification(Object _obj)t{ 
this.obj = _obj; 
} 


@Override 
public boolean isSatisfiedBy(Object candidate) { 
// 根 据 基 准 对 象 和 候选 对 象 ， 进 行业 务 判断 ， 返 回 boolean 


return false,; 


然后 束 古 看 坚 么 使 用 了 ， 场 景 类 如 代码 清单 38-28 所 示 。 


代码 清单 38-28 场景 


public class Client { 
public static void main(String[] args) { 
村 分 析 的 对 象 
ArrayList<Object> list = new ArrayList<Object>() ; 
// 定 义 两 个 业务 规格 书 
ISpecification Spec1 = new BizSpecification(new 


Object()); 
ISpecification spec2 = new BizSpecification(new 


// 规 则 的 调用 
for(Object obj:1list)t{ 
if(speci.and(spec2).isSatisfiedBy(obj))t{ 


Object( )); 


//and 操 作 


System,out,printJln(obj ) ; 


规格 模式 已 经 是 一 个 非常 具体 的 应 用 框架 了 (相对 于 23 个 设计 模 
式 ) ， 大 家 遇 到 类 似 多 个 对 象 中 筛选 查找 ， 或 者 业务 规则 不 适 于 放 在 
任何 已 有 实体 或 值 对 象 中 ， 而 且 规 则 的 变化 和 组 合 会 掩盖 那些 领域 对 
象 的 基本 含义 ， 或 者 是 想 目 己 编写 一 个 类 似 LINQ 的 语言 工具 的 时 候 就 
可 以 照搬 这 部 分 代码 ， 只 要 实现 自己 的 逻辑 规格 书 即 可 。 


38.2 对 象 池 模 式 


上 上 周 二， 师兄 过 来 找 我 ， 他 负责 运 维 一 个 大 型 新 闻 网 站 ， 说 是 网 
站 出 现 性 能 ， 让 我 帮忙 分 析 调 优 。 我 这 几 天 正好 内 得 手 痒 ， 同 时 又 卖 
个 人 情 ， 何 乐 而 不 为 呢 。 于 是 我 们 俩 就 到 机 房 赔 点， 人 退 查 问题 。 


38.2.1 正确 的 池 化 


简单 说 明 一 下 该 系统 的 场景 ， 这 是 一 个 专业 的 新 闻 退 踩 网 站 ， 关 
注 的 是 专业 新 闻 的 深度 ， 在 行业 内 具有 相当 大 的 影响 力 。 最 近 一 段 时 
间 内 出 现 偶 发 性 缓慢 ， 从 监控 情况 上 看 ， 啊 应 时 间 在 2 秒 以 上 ， 由 于 最 
近 软 硬件 环境 都 没有 变更 过 ， 因 此 直觉 判断 ， 最 快捷 、 直 观 的 解决 方 
案 就 是 增加 DB 硬件 设备 。 但 由 于 东家 是 穷 惯 了 ， 不 同意 在 没有 彻 查 问 
题 之 前 而 依靠 增强 硬件 来 解决 问题 ， 于 是 我 们 这 些 软件 工程 师 束 忙活 
起 来 了 。 


网 站 首页 内 容 基 本 都 是 静态 的 〈 轮 询 生成 ) ， 唯 一 的 动态 部 分 是 
网 站 的 激励 语 ， 比 如 “ 积 一 时 之 蹲 步 ， 哟 千里 之 遥 程 ”`“ 业 精 于 勤 ， 蕊 
于 婚 ; 行 成 于 思 ， 毁 于 随 ” 等 励志 语句 ， 这 有 是 一 个 稍 单 的 SQL 随机 碍 询 

结 朱 ， 表 中 的 数量 在 5000 条 左右 ， 而 且 绪 构 和 商 单 ， 查 询 性 能 不 是 问 
题 。 示 例 代 码 如 代码 清单 38-29 所 示 。 


代码 清单 38-29 无 缓存 的 SQL 随机 读 取 


@Service 
public class WisdomProvider { 
Q@Autowire 
private WisdomDao wisdomDao; 
public String getoneword() { 
return wisdomDao.randomOnewisdom( ); 
} 


对 于 代码 中 的 @Service、@Autowire 注 解 ， 做 过 Spring 开 发 的 都 
懂 ， 这 是 一 个 典型 的 三 层 架 构 ，WisdomDao 的 randomOneWisdom 方 法 
是 通过 数据 库 随 机 函数 查询 一 条 记录 。 在 跟踪 过 程 中 ， 发 现 高 峰 期 数 
据 库 连 接 偶尔 出 现 占 满 情 况 ， 而 且 都 是 查询 该 表 (顺便 说 下 ， 该 数据 
库 的 随机 查询 算法 有 缺陷 ) ， 问 题 找 到 了 : 每 一 次 访问 都 会 直接 查询 
数据 库 ， 没 有 缓存 。 通 常情 况 下 ， 这 没有 问题 ， 但 是 在 高 并 发 的 情况 
下 ， 例 如 在 10 万 PV 的 压力 下 服务 器 基本 就 垮 掉 了 ， 这 是 非常 严重 的 问 


题 。 


怎么 解决 昵 ? 好 办 ， 引 入 一 个 对 象 池 ， 把 这 5000 条 记录 (根据 评 
估 最 多 不 超过 20000 条 记录 ) 在 启动 时 直接 加 载 到 内 存 中 ， 在 需要 时 再 
从 内 存 中 取得 ， 以 后 查询 不 再 与 数据 库 交 互 。 示 例 代 码 如 代码 清单 38- 
30 所 示 。 


代码 清单 38-30 增加 缓存 后 的 随机 读 取 


@Service 
public class WisdomProvider { 
Q@Autowire 


private WisdomDao wisdomDao; 
private List<String> wisdoms = null; 
@PostConstruct 
public void init() { 
wisdoms = wisdomDao.getAll(); 


} 
public String getOneword() { 

return RandomUtils.getOne(wisdoms ) ， 
} 


@PostConstruct 注 解 的 作用 是 Spring 容器 在 启动 完毕 后 ， 直 接 执行 
init 方 法 ， 一 次 性 读 取 所 有 的 数据 ， 然 后 在 应 用 运行 期 间 不 再 与 数据 库 
交互 ， 直 接 从 List 列 表 中 获取 数据 。 通 过 这 样 的 修正 ， 系 统 性 能 有 了 大 
幅 提 升 ， 在 不 增加 人 硬件 的 情况 下 ， 彻 抬 解 决 了 性 能 问题 。 这 就 古 对 和 象 
池 模 式 。 


38.2.2 对 象 池 模 式 的 意 


对 象 池 模 式 ， 或 者 称 为 对 象 池 服务 ， 其 意图 如 下 : 


通过 循环 使 用 对 象 ， 减 少 资 源 在 初始 化 和 释放 时 的 昂贵 损耗  。 


注意 ”这 里 的 “昂贵 ”可 能 是 时 间 效 益 (如 ' 
效益 《如 并 行 处 理 ) ， 在 大 多 的 情况 下 , “昂贵” 指 性 能 。 
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简单 地 说 ， 在 需要 时 ， 从 池 中 提取 ; 不 用 时 ， 放 回 池 中 ， 等 待 下 
一 个 请 求 。 典 型 例子 十 连接 池 和 线程 池 ， 这 是 我 们 开发 中 经 第 接触 到 


的 。 类 图 如 图 38-6 所 示 。 


ObjectPool 


十 CheckOut() 
十 CheckIn() 


图 38-6 对 象 池 模式 通用 类 图 


对 象 池 提 供 两 个 公共 的 方法 : checkoOut 负 责 从 池 中 提取 对 和 象 ， 
checkIn 负 责 把 回收 对 象 (当然 ， 很 多 时 候 checkIn 已 经 自动 化 处 理 ， 不 
需要 显 式 声明 ,如 连接 池 ) ， 对 象 池 代码 如 代码 清单 38-31 所 示 。 


代码 清单 38-31 对 象 池 示例 代码 


public abstract class ObjectPool<T> { 
// 容 器 ， 容 纳 对 象 
private Hashtable<T, ObjectStatus> pool = new 
Hashtable<T, ObjectStatus>(); 
// 初 始 化 时 创建 对 象 ， 并 放 入 到 池 中 
public ObjectPool() { 
pool.put(create(), new ObjectStatus()); 


} 
// 从 Hashtable 中 取出 空 闪 元 素 
public synchronized T checkOut() { 
// 这 是 最 简单 的 策 权 
for (Tt : pool.keySet()) { 
if (pool.get(t).validate()) { 
pool.get(t).setUsing(); 
return tt; 


} 


return null; 


} 
// 归 还 对 象 


public synchronized void checkIn(T t) { 
pool.get(t).setFreel(); 


} 
class ObjectStatus { 
// 占 用 
public void setUsing() { 


} 
// 释 放 
public void setFree() { 
// 注 意 : 若 T 是 有 状态 ， 则 需要 回归 到 初始 化 状态 


} 

// 检 查 是 否 可 用 

public boolean validate() { 
return false; 

} 


} 
// 创 建 池 化 对 象 
public abstract T create(); 


这 是 一 个 简单 的 对 象 池 实现 ， 在 实际 应 用 中 还 需要 考虑 池 的 最 小 
值 、 最 大 值 、 池 化 对 象 状 态 〈 若 有 的 话 ， 需 要 重点 考虑 ) 、 异 常 处 理 
(如 满 池 情况 ， 等 方面 ， 特 别 是 池 化 对 象 状态 ， 才 是 有 状态 的 业务 对 
象 则 需要 重点 关注 。 


38.2.3 最 佳 实践 


把 对 象 池 化 的 本 意 是 期 望 一 次 性 初始 化 所 有 对 象 ， 减 少 对 象 在 初 
人 化 上 的 昂贵 性 能 开销 ， 从 而 提高 系统 整体 性 能 。 然 而 池 化 处 理 本 身 
也 要 付出 代价 ， 因 此 ， 并 非 任 何 情况 下 都 适合 采用 对 象 池 化 。 


通常 情况 下 ， 在 重复 生成 对 象 的 操作 成 为 影响 性 能 的 关键 因素 
时 ， 才 适合 进行 对 象 池 化 。 但 是 大 池 化 所 能 带 来 的 性 能 提高 并 不 显著 


或 重要 的 话 ， 建 议 放 弃 对 象 池 化 技术 ， 以 保持 代码 的 简明 ， 转 而 使 用 
更 好 的 硬件 来 提高 性 能 为 佳 。 


对 象 池 技术 在 Java 领 域 已 经 非常 成 熟 ， 只 要 做 过 企业 级 开发 的 人 
员 ， 基 本 都 用 过 C3P0、DBCP、Proxool 等 连接 池 ， 也 配置 过 
minPoolSize、maxPoolSize 等 参数 ， 这 是 对 象 池 模式 的 典型 应 用 。 在 实 
际 开发 中 若 需 要 对 象 池 ， 建 议 使 用 common-pool 工 具 包 来 实现 ， 简 单 、 
快捷 、 高 效 。 


[1] 原文 是 Avoid expensive acquisition and release of resources by recycling 


objects that are no longer in use ° 


38.3 雇工 模式 


38.3.1 雇工 合作 


我 是 一 个 定 聚 (当然 只 是 想象 中 的 ， 家 里 有 很 多 佣 人 ， 家 务 活 
基本 上 不 用 我 动手 ， 我 只 要 动 动 口 丈 可 以 了 ， 在 这 里 每 个 人 都 有 不 同 
分 工 ， 我 可 以 指挥 厨师 把 厨房 弄 干将， 这 和 是 他 的 地 盘 ;， 我 可 以 指挥 园 
丁 把 花园 收拾 干净 、 床 亮 ， 这 和 是 他 应 该 做 的 ， 我 还 可 以 让 裁缝 把 我 的 
衣服 收拾 干净 。 注 意 看 ， 我 这 里 列举 出 的 三 个 对 象 《厨师 、 园 本 、 裁 
颖 ) 都 具有 相同 的 功能 : 清河。 从 另 一 方面 说 ， 厨 房 、 人 花园、 衣服 都 
具有 被 清 涪 的 特性 ， 我 们 从 这 一 例子 入 手 ， 编 写 代码 如 代码 清单 38-32 
所 示 。 


代码 清单 38-32 三 个 对 象 的 被 清洁 特质 


// 可 以 被 清洁 的 对 象 

public interface Cleanable { 
// 被 清 活 
public void celaned(); 


} 
// 花 园 
class Garden implements Cleanab]et 
public void celaned(){ 
System,out .println(“ 花 园 被 清洁 干净 ”); 


} 
// 厨 房 
class Kitchen implements Cleanab]et 
public void celaned(){ 
System.out .println(“ 厨 房 被 清洁 干净 ”); 


} 
} 
// 衣 服 


class Cloth implements Cleanablef 
public void celaned(){ 
System,.out,println(“ 衣 服 被 清洁 干净 ”) ; 


三 个 对 象 (厨房 、 花 园 、 衣 服 ) 的 共同 特征 抽取 出 来 ， 同 时 也 需 
要 把 厨师 、 裁 缝 、 园 丁 的 共同 特征 也 抽象 出 来 。 从 我 这 个 主人 的 角度 
看 来 ， 他 们 三 者 都 是 清洁 者 ， 只 是 输入 的 对 象 不 同 而 已 ， 如 代码 清单 
38-33 所 示 。 


代码 清单 38-33 抽象 的 清洁 者 


public class Cleaner { 
// 清 洁 
public void clean(Cleanable clean)t{ 
clean.celaned(); 


非常 简单 ， 束 这 么 一 个 清洁 者 束 可 以 厨师 、 园 耳 、 和 裁缝 。 我 们 再 
编写 一 个 场景 类 ， 摘 述 一 下 发 生 了 什么 事 ， 如 代码 清单 38-34 所 示 。 


代码 清单 38-34 场景 


public class Client { 

public static void main(String[] args) { 
// 厨 师 清 洁 厨 房 
Cleaner cookie = new Cleaner(); 
cookie.clean(new Kitchen()); 
// 园 丁 清洁 花园 
Cleaner gardener = new Cleaner(); 
gardener .clean(new Garden()); 


// 裁 颖 清洁 衣服 


Cleaner tailer = new Cleaner(); 
tailer.clean(new Cloth()); 


场景 写 完了 ， 运 行 一 下 ， 束 可 以 看 到 厨师 打扫 了 厨房 ， 园 丁 清 党 
了 花园， 裁缝 请 污 了 衣服 。 代 码 很 简单 ， 但 是 诸位 有 没有 发 觉 这 和 我 
们 通常 的 分 析 有 古 不 同 的 。 通 肖 的 做 法 是 ， 既然 厨 病 、 园 丁 、 裁 颖 都 具 
有 清洁 的 功能 ， 那 吏 定 义 一 个 接口 撒 述 三 者 的 清洲 功能 ， 然 后 再 定义 
三 个 类 ， 分 别 代表 厨师 、 园 本 、 裁 颖 实现 这 个 接口 。 这 有 是 一 种 常用 的 
解决 办 法 ， 可 以 解决 该 问题 ， 但 今天 我 们 从 另外 一 个 侧面 进行 分 析 ， 
引出 一 个 新 的 模式 :雇工 模式 。 


38.3.2 雇工 模式 的 意图 


雇工 模式 也 叫做 仆人 模式 (Servant Design Pattem) ， 其 意图 是 : 


雇工 模式 是 行为 模式 的 一 种 ， 它 为 一 组 类 提供 通用 的 功能 ， 而 不 
需要 类 实现 这 些 功能 ， 它 是 命令 模式 的 一 种 扩展 上 。 


看 看 我 们 的 例子 ， 厨 师 、 裁 颖 、 园 丁 是 一 组 类 ， 都 具有 清 话 的 能 
力 ， 但 是 我 们 却 没 实现 ， 而 是 采用 一 种 更 优雅 的 方式 来 实现 ， 这 束 旦 
雇工 模式 。 雇 工 模式 的 类 图 如 图 38-7 所 示 。 


<<interface>> 
IServiced en 


八 八 


图 38-7 雇工 模式 通用 类 疼 


在 类 图 中 ，IServiced 是 用 于 定义 “一 组 类 ”所 具有 的 功能 ， 其 示例 代 
码 如 代码 清单 38-35 所 示 。 


代码 清单 38-35 通用 功能 


public interface IServiced { 
// 具 有 的 特质 或 功能 


public void serviced(); 


上 


针对 不 同 的 服务 对 象 具 备 不 同 的 服务 内 容 ， 也 就 是 具体 的 功能 实 
现 IServiced 接 口 即 可 ， 示 例 代 码 如 代码 清单 38-36 所 示 。 
代码 清单 38-36 定义 具体 功能 


public class Serviced1 implements IServiced { 
public void serviced(){ 


} 
public class Serviced2 implements IServicedf{ 


public void serviced(){ 


功能 定义 完毕 后 ， 我 们 需要 由 一 个 雇工 来 执行 这 些 功 能 。 简 单 地 
说 ， 就 是 需要 有 一 个 执行 者 ， 可 以 把 一 组 功能 聚集 起 来 ， 示 例 代 码 如 
代码 清单 38-37 所 示 。 


代码 清单 38-37 雇工 类 


public class Servant { 
// 服 务 内 容 


public void service(IServiced serviceFuture)t{ 
serviceFuture.serviced(); 


在 整个 雇工 模式 中 ， 所 有 具有 IServiced 功 能 的 类 可 以 实现 该 接口 ， 
然后 由 雇工 类 Servant 进 行 集 合 ， 完 成 一 组 类 不 用 实现 通用 功能 而 具有 
相应 职能 的 目的 。 


38.3.3 最 佳 实践 


在 日 钊 的 开发 过 程 中 ， 我 们 可 能 已 经 接触 过 雇工 模式 ， 只 有 是 
没有 把 它 抽 取出 来 ， 也 没有 汇编 成 册 。 或 许 大 家 已 经 看 出 这 与 命 
式 非 常 相似 ， 读 者 可 以 回顾 第 15 章 ， 


令 模 
会 发 现 雇工 模式 是 命令 模式 的 一 
种 简化 ， 但 它 更 符合 我 们 实际 的 需要 ， 更 容易 引入 开发 场景 中 。 


[1] 原文 是 A behavioral pattern used to offer some functionality to a group 


of classes without defining that functionality in each of them ° 


38.4 黑板 模式 
38.4.1 黑板 模式 的 意图 
黑板 模式 (Blackboard Design Pattern) 是 观察 者 模式 的 一 个 扩展 ， 


知名 度 并 不 高 ， 但 是 我 们 使 用 的 范围 却 非常 广 。 黑 板 模 式 的 意图 如 
下 : 


允许 消息 的 读 写 同 时 进行 ， 广泛 地 交互 消息 1 。 


简单 地 说 ， 黑 板 模 式 允 许多 个 消息 读 写 者 同时 存在 ， 消 息 的 生产 
者 和 消费 者 完全 分 开 。 这 就 像 一 个 黑板 ， 任 何 一 个 教授 (消息 的 生产 
者 ) 都 可 以 在 其 上 书写 消息 ， 任 何 一 个 学 生 (消息 的 消费 者 ) 都 可 以 
从 黑板 上 读 取 消息 ， 两 者 在 空间 和 时 间 上 可 以 解 厢 ， 并 且 互 不 干扰 。 
示意 图 如 图 38-8 所 示 。 


图 38-8 黑板 模式 示意 图 


看 到 这 个 图 大 家 可 能 会 说 ， 这 不 是 一 个 简单 的 消 轧 广播 吗 ? 是 
的 ， 确 实 如 此 ， 黑 板 模 式 确实 是 消 恩 的 广播 ， 主 要 解决 的 问题 是 消 筷 
的 生产 者 和 消费 者 之 间 的 耦合 问题 ， 它 的 核心 是 消息 存储 (黑板 ) ， 
它 存 储 所 有 背 恩 ， 并 可 以 随时 被 读 取 。 当 消 居 生 产 者 把 消息 写 入 到 消 
恩人 仓库 后 ， 其 他 消费 着 束 可 以 从 仓库 中 读 取 。 当 然 ， 此 时 消 居 的 写 入 
者 也 可 以 变 身 为 消息 的 阅读 者 ， 读 写 者 在 时 间 上 解 厢 。 对 于 这 些 消 
息 ， 消 费 者 只 需要 关注 特定 消息 ， 不 处 理 与 自己 不 相关 的 消息 ， 这 一 
扩 通 前 通过 过 滤 右 来 实现 。 


38.4.2 黑板 模式 的 实现 方法 


黑板 模式 一 般 不 会 对 架构 产生 什么 影响 ， 但 它 通常 会 要 求 有 一 个 
清晰 的 消息 结构 。 墨 板 模式 一 般 都 会 提供 一 系列 的 过 滤器 ， 以 便 消 息 
的 消费 考 不 再 接触 到 与 目 己 无 关 的 消 电 。 在 实际 开发 中 ， 黑 板 模式 间 
见 的 有 两 种 实现 方式 。 


e 数据 库 作为 黑板 


利用 数据 库 充 当 黑 板 ， 生 产 者 更 新 数据 信息 ， 不 同 的 消费 者 共享 
数据 库 中 信息 ， 这 是 最 常见 的 实现 方式 。 该 方式 在 技术 上 容易 实现 ， 


开发 量 较 少 ， 熟 悉 度 较 高 。 缺 点 是 在 大 量 消 轧 和 高 频率 访问 的 情况 


在 该 模式 下 ， 请 恩 的 读 取 走 通过 请 费 着 主动 * 拉 取 ”， 因 此 该 模式 
也 叫做 “ 拉 模 式 ”。 
e 消 轧 队列 作为 黑板 


以 消 居 队 列 作为 黑板 ， 通 过 订阅 -发 布 模型 即 可 实现 黑板 模式 。 这 
也 是 黑板 模式 被 淡 起 的 一 个 重要 原因 : 消息 队列 (Message Queue) 已 
经 非常 普及 了 ， 做 Java 开 发 的 已 经 没有 几 个 不 知道 消 因 队列 的 。 


在 该 模式 下 ， 消 费 首 接收 到 的 消 居 是 被 主动 推送 过 来 的 ， 因 此 该 
模式 也 称 为 “ 推 模式 ”。 


提示 。 黑板 模式 不 做 详细 讲解 ， 因 为 我 们 现在 已 经 在 大 量 使 用 消 
息 队 列 ， 既 可 以 做 到 消息 的 同步 处 理 ， 也 可 以 实现 异步 处 理 ， 相 信 大 
家 已 经 在 开发 中 广泛 使 用 了 ， 它 已 经 成 为 跨 系统 交互 的 一 个 事实 标准 
了 了。 


[1] 原文 是 allows multiple readers and writers. Communicates information 


system-wide ° 


38.5 空 对 象 模式 
空 对 象 模 式 〈Null Object Pattern) 是 通过 实现 一 个 默认 的 无 意义 
对 象 来 避免 null 值 出 现 ， 人 简单 地 说 ， 束 是 为 了 避免 在 程序 中 出 现 null 值 


判断 而 诞生 的 一 种 第 用 设计 方法 。 


38.5.1 空 对 象 模 式 的 例子 


举 个 徐 单 的 例子 来 说 明 ， 我 们 写 一 个 听 动 物 叫 声 的 模拟 程序 ， 如 
代码 清单 38-38 所 示 。 


代码 清单 38-38 动物 叫 声 


// 定 义 动物 接口 
public interface Animal { 
public void makeSound ( ) ; 


} 
// 定 义 一 个 小 狗 
class Dog implements Animal{ 
public void makeSound(){ 
System.out.println(“Wang Wang Wang!”); 
} 


然后 再 定义 一 个 人 来 听 动 物 的 叫 声 ， 如 代码 清单 38-39 所 示 。 


代码 清单 38-39 听 动 物 叫 声 的 人 


public class Person { 


// 听 到 动物 叫 声 


public void hear(Animal animal)t{ 
if(animal !=null)t{ 
animal.makeSound(); 


也 许 你 觉得 程序 没有 什么 问题 ， 输 入 参数 animal 是 应 该 做 空 值 判 
断 。 但 是 ， 我 们 这 样 思 考 : 在 一 个 完整 的 系统 中 ，animal 对 象 是 如 何 
产生 ? 什么 原因 会 产生 null 值 ? 如 果 我 们 能 够 控制 住 null 值 的 产生 ， 是 
不 是 就 可 以 去 掉 这 个 空 值 判断 了 ? 那 这 样 ， 程 序 是 不 是 更 易 读 更 简 
单 ? 好 ， 我 们 就 编写 一 个 更 完美 的 程序 ， 增 加 一 个 NullAnimal 类 ， 如 
代码 清单 38-40 所 示 。 


代码 清单 38-40 增加 一 个 NullAnimal 


class NullAnimal implements Animalt{ 
public void makeSound(){ 
} 


} 


增加 了 NullAnimal 类 后 ， 在 Person 类 中 就 不 需要 "animal!=null" 这 人 句 
话 了 ， 因 为 我 们 提供 了 一 个 实现 接口 的 所 有 方法 ， 不 会 再 产生 null 对 
象 。 想 象 一 个 Web 项 目 中 ，animal 对 象 可 能 由 MVC 框 架 映 射 产 生 ， 我 
们 只 要 定义 一 个 默认 的 映射 对 象 是 NullAnimal， 束 可 以 解决 空 值 判断 
的 问题 ， 提 升 代码 的 可 读 性 。 这 就 是 空 对 象 模式 〈 一 些 项 目 组 把 它 作 
为 编码 规范 的 一 部 分 ) ， 非 常 简单 ， 但 非常 实用 。 


38.5.2 最 佳 实践 


空 对 象 模式 是 通过 衬 代 码 实现 一 个 接口 或 抽象 类 的 所 有 方法 ， 以 
满足 开发 需求 ， 人 向 化 程序 。 它 如 此 简单 ， 以 至 于 我 们 经 常 在 代码 中 看 
到 和 使 用 ， 对 它 已 经 邵 视 无 腾 了 ， 而 它 无 论 古 事前 规划 或 事后 重 构 ， 
都 不 会 对 我 们 的 代码 产生 太 大 冲击 ， 这 也 是 我 们 “ 比 视 ” 它 的 根本 原 
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